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ABSTRACT 



This thesis examines the requirement for a Management 
Information and Control System (MICS) by the Sidewinder 
Program Office at the Naval Weapons Center (NWC ) , China 
Lake, California. Specifically, it examines the need and 
criteria for a MICS to adequately fulfill the control and 
planning aspects of the program management process at the 
Sidewinder Program Office at NWC (SPO/NWC) . The thesis dis- 
cusses the considerations and criteria appropriate for a 
viable MICS in general application and examines the existing 
SPO/NWC environment and MICS. Roles, responsibilities, 
information flows, and controls with respect to the SPO/NWC 
are identified. The authors stipulate the information and 
control requirements necessary to ensure successful SPO/NWC 
accomplishment of responsibilities and evaluate the current 
system in light of these requirements. The current system 
is found to be inadequate and the authors present a con- 
ceptual model of a MICS for the SPO/NWC which would provide 
the planning and control capabilities required. 
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I. INTRODUCTION 



A. BACKGROUND 

1 . The Matrix Organization and Program Manager 

Concept . 

Project management is the central organizational 
device for integrating the effort required to develop weap- 
ons systems within the Department of the Navy. The primary 
characteristic of project management is organization by 
purpose and output in contrast to organization around func- 
tions, skills or disciplines as found elsewhere in govern- 
ment and in industry. Both types of organizations are used 
in Navy Weapon Systems Acquisition and are essential to 
effective and economical weapon systems development and 
procurement. The functional organization is superior for 
advancing the state of the art. It brings together the 
skills, equipment and physical facilities required for 
effective performance. The project management concept of 
organization by purpose is necessary for the coordination 
and integration of the output of the functional organization 
in order to insure that desired program purposes are accom- 
plished. 

2 . Management Control and Information . 

Management control over all aspects of the project 
is delegated to the Program Manager in the program charter 
issued by the cognizant authority and is vital to the 
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efficient and effective functioning of a Program Office, 
Having the authority for program control and actually achiev 
ing effective program control is, particularly within a 
matrix configuration, another matter. Since he does not 
have line authority over individuals outside the Program 
Office, the Program Manager's task is one of exercising 
tact, diplomacy and leadership in enlisting the cooperation 
of both seniors and subordinates in the functional organiza- 
tions that actually provide the support for the program. 

The degree of management control and its effective- 
ness is directly proportional to the information flow to and 
from the program office. Information exchanges upward, 
downward and laterally must be established and nurtured. 

The outward information flow provides the guidelines to 
accomplish the goals of the program office. In order for 
this tool to be effective, however, information must be fed 
back to the program office. This is the information used in 
management appraisal - assessing the effectiveness of exist- 
ing policies, developing and evaluating policy changes, 
measuring progress, replanning, rescheduling and all the 
other activities necessary in accomplishing objectives and 
utilizing government and contractor resources to the fullest 
extent possible. The existence of this "closed-loop" charac 
teristic in the information flow is essential for successful 
program management. 
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An effective "directive and reporting" system, 
while an important aspect of communication, will not suffice 
for an information system in program management. The pre- 
paration time alone for such documents obviates their use in 
real-time program management. A successful program office 
will utilize a combination of communication methods - letter, 
message, telephone, telecopier, film, conferences, etc. 
Building an information network and maintaining its effec- 
tiveness is essential to the successful accomplishment of 
the primary tasks of the Program Manager. 

3 . Sidewinder Program Management . 

a. Organizational Relationships 

Project management in the Naval Air Systems 
Command (NAVAIR) cuts across the functional organization 
under the Chief of Naval Material (CNM) and serves as a 
single point of contact and effort to get the job done. 
Project managers operate under charters issued by CNM or by 
the Commander of a Systems Command. NAVAIR has cognizance 
for the Sidewinder missile and the Infrared Missiles Program 
Manager (PMA-259) , is chartered by and reports directly to 
the Commander of the Naval Air Systems Command. The project 
charter prescribes the scope of authority, responsibility 
and operating relationships of PMA-259. 

The Sidewinder Program Office at the Naval 
Weapons Center (SPO/NWC) at China Lake, is also organized 
around a project management matrix concept. The project 
management approach is used to provide an integrated, single 
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point-of-contact at the Naval Weapons Center (NWC) and 
maintain the emphasis on output required to bring a new 
weapon into operational service. The SPO/NWC provides this 
interface and point-of-contact between NWC and other DoD 
and/or civilian activities. The SPO/NWC is also the inter- 
face for the program to the functional codes within NWC 
which actually provide the services and accomplish the tasks 
required. 

The SPO/NWC is administratively located in 
the Engineering Design Division of the Engineering Depart- 
ment. The SPO/NWC tasks and funds continuing efforts in 
several divisions/departments throughout NWC. Other branches 
are intermittently tasked to support the analysis, design, 
testing, and evaluation functions necessary to put the 
Sidewinder missile system into Navy and Air Force arsenals, 
b. Role and Responsibility of SPO/NWC 

NWC is tasked with the responsibility for the 
technical support of the Sidewinder missile (AIM-9) systems 
by NAVAIR. This technical support task is comprised of 
production support, development, testing, and Integrated 
Logistics Support (ILS) functions. In order to accomplish 
these fundamental functions, tremendous coordination is 
required between NWC and NAVAIR, Participating Field Activi- 
ties (PFAs) , co-sponsoring Air Force activities, and primary 
and secondary source contractors for AIM-9 hardware and 
software. In addition, the coordination of tasks distri- 
buted among the NWC functional codes must be accomplished. 
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SPO/NWC provides the coordination required in both these 
areas . 

Overall responsibility for tasking and fund- 
ing commitments are received by the SPO/NWC in the form of 
AIRTASK and Work Unit Assignment documents from NAVAIR and 
Project Orders from other Navy and Air Force field activi- 
ties. The SPO/NWC release-to-work documents are Task Agree- 
ments to the NWC supporting codes. Project Orders to other 
field activities and contracts to civilian industry. 

c. The Management Information and Control Prob- 
lem Within SPO/NWC 

The myriad of technical, operational, finan- 
cial and administrative details involved in managing the 
AIM-9 program at NWC, are handled by the twelve individuals 
in the SPO/NWC, and many others throughout the NWC support- 
ing codes. These individuals each maintain personal files 
and records; however, no single file or set of files aggre- 
gates or integrates the information contained in these 
files. Much of the information flow is verbal, or in in- 
formal notes and memoranda from many different sources and 
on many diverse subjects, which is not captured in any 
formal file for use by the Program Manager. The present 
loss of information through inaccessibility (travel, leave, 
etc.) of key individuals and lack of proper documentation 
results in considerable time being consumed in data searches 
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and duplication of effort. The combination of these situa- 
tions results in a lack of overall visibility into total 
organizational workload for planning purposes and insuffi- 
cient control of progress in accomplishment of assigned 
tasks . 

B. THESIS HYPOTHESIS AND OBJECTIVES 
1. Hypothesis . 

The hypothesis of this thesis is that the Program 
Manager concept and utilization of the matrix organization 
technique for program management accentuates the need for a 
comprehensive and timely management control system within 
the context of a program management information system 
(MIS) . In particular, the SPO/NWC Manager has a definite 
requirement for a comprehensive, responsive management 
information and control system (MICS) to enable him to 
properly perform the multitude of tasks required of his 
organization. The authors believe that the current control 
system employed at the SPO/NWC is not adequate to fulfill 
the need. It requires an inordinate amount of managerial 
time to monitor task completion and the system is not com- 
prehensive enough to insure that all tasks are monitored. 

In addition, it does not provide adequate visibility to 
allow for proper program planning and allocation of re- 
sources. It is further believed that an improved system 
would be less time consuming and provide information for 
successful program planning and control. 
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2 . Objectives 



The objectives of this thesis are: 1) to identify 

and discuss the criteria and considerations appropriate for 
a viable MICS, 2) to examine the existing SPO/NWC environ- 
ment and MICS to identify roles, responsibilities, informa- 
tion flow and controls, 3) to stipulate the information and 
control requirements deemed necessary by the authors to 
insure successful SPO/NWC control, 4) to evaluate the cur- 
rent MICS and ascertain the need for improvement, and 5) to 
recommend a MICS framework for subsequent system design and 
implementation . 

C . METHODOLOGY 

1. Process and Scope 

The development of MISs has evolved into a process 
much the same as the weapon system acquisition process. 
Current literature calls for a project manager concept 
employing "user-producer" (management-designer) dialog, and 
delineates a system life cycle approach. Although the 
descriptions of this system life cycle range in the litera- 
ture from those with four phases to one model with twelve 
phases, the concepts are the same. The system passes 
through various stages in development from inception to full 
utilization. 

One such model of the systems' life cycle was 
presented by J. T. Rigo[l] and portrayed an eight-phase 
development. The eight phases are depicted in Table I-A. 
This thesis will encompass the first three phases in the 
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PHASE 



EVENTS /TASKS 



Initiation 


Statement of the Problem 
Statement of Objectives 
Statement of Anticipated Benefits 


Survey 


Documentation of Current Situation 


Requirements 

( 


Stipulation of User Requirements 
-outputs 

Identification of Alternative 
Gross Designs 

-inputs, outputs, processing 


Preliminary Design 


Selection of a Gross Design 
Alternative 

Preparation of Functional 
Specifications 

Cost/Benefit Analysis 


Detail Design 


Preparation of System and Program- 
ming Specifications 

Plans for Training, Forms and 
Manual Preparation 


Development 


Programs Written 

Hardware Procured 

Forms and Procedures Designed 


Implementation 


System Tested in Parallel with 
Existing System 

Operational Acceptance 


Evaluation 


Cost and Performance Evaluated 

Modifications Implemented as 
Required 



INFORMATION SYSTEM DEVELOPMENT STRUCTURE [1] 

TABLE I -A 
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process and the selection of a gross design alternative. It 
is felt that this is the extent of the effort which can be 
accomplished within the time constraints imposed and the 
level of technical expertise of the authors. 

Another limitation of the scope of the thesis is 
in the area of the SPO/NWC functions . As indicated pre- 
viously, the SPO/NWC has the responsibility for all techni- 
cal support of the Sidewinder missile system. While the 
problems and objectives described earlier are applicable to 
the total SPO/NWC operation, this thesis will concentrate 
only on the AIM-9L Production Support functions in its 
analysis. This limitation is self-imposed in order to 
reduce the research effort to a level commensurate with time 
restrictions. It is felt that this limitation is not detri- 
mental to the overall effort in that AIM-9L Production 
Support represents about forty percent of the SPO/NWC work- 
load and is representative of the remaining efforts in terms 
of management planning and control. 

2 . Personal Contact 

Information for this thesis has been gathered 
largely through personal contact with key members of the 
SPO/NWC. One of the authors is the Program Manager of the 
SPO/NWC and the other author made a total of five visits to 
NWC over a period of nearly six months. During these visits, 
management information and control aspects of the program 
were discussed in depth, and pertinent technical features 
were reviewed with key personnel. 
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3. Review of Current Literature 



Basic research was conducted in order to gain 
knowledge and appreciation in the areas of management con- 
trol and planning and management information systems. This 
was accomplished by reviewing current periodicals , books , 
and reports. The more pertinent of the material reviewed is 
listed in the Bibliography. 

4 . Analysis 

Decision level analysis and information flow 
analysis were both employed in the evaluation of the facts 
for this thesis. Techniques used in these analyses included 
organizational charting and information and systems flow 
charting. Input and output volume and frequency data were 
collected by total item count over a designated period. 

D. THESIS ORGANIZATION 

This thesis is organized to coincide with and achieve 
the thesis objectives previously outlined. Chapter II is a 
survey of the literature search in the areas of planning and 
control and MIS, and includes the design considerations and 
criteria currently held by various authors as appropriate to 
the MICS development process. It presents two conceptual 
frameworks within which to view a MICS and the implications 
of those frameworks upon the MICS in the areas of informa- 
tion requirements, system characteristics, and the system 
design process. The chapter concludes with a discussion of 
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criteria for selection of a MICS type for a specific appli- 
cation. Readers familiar with MICS concepts and capabili- 
ties need not read this chapter. 

Chapter III examines the existing SPO/NWC environment 
and MICS. It explores the organizational relationships of 
those activities which interact with the SPO/NWC in the 
Sidewinder Program, and the roles, responsibilities, and 
information flows associated with these relationships. Also 
delineated in this chapter are the processes of task assign- 
ment within these relationships and the current SPO/NWC 
systems utilized for planning and control purposes. This 
chapter represents the Survey Phase of the Rigo MICS develop- 
ment model previously outlined. 

The establishment of the information and control require- 
ments necessary to ensure successful SPO/NWC operation are 
outlined in Chapter IV. First, general goals and objectives 
for a viable SPO/NWC MICS are presented and the current 
information and control systems are evaluated in light of 
those goals and objectives. Secondly, a conceptual model 
for an appropriate SPO/NWC MICS is presented. Thirdly, the 
proposed conceptual model is further defined in terms of 
more specific system outputs, data processing required, and 
data inputs required. Chapter IV is an application of the 
Rigo Requirements Phase to SPO/NWC. 

Finally, Chapter V presents a brief summary of the 
thesis to that point and outlines the conclusions and recom- 
mendations of the authors. 
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II. MANAGEMENT INFORMATION AND CONTROL SYSTEMS 



DESIGN CONSIDERATIONS AND CRITERIA 
A. BACKGROUND 

A comprehensive search of current literature was under 
taken to determine if a model for the design of management 
information and control systems existed. For this thesis, 
the term "model" is defined as a set of formulae or consid- 
erations which when entered with appropriate data would 
result in a specific MICS design. No such model was found. 
What was discovered was a recurring description of the 
process of MICS development as briefly outlined in the 
methodology and the stipulation of certain information 
characteristics and classifications and system characteris- 
tics which when analyzed in the light of user requirements 
and constraints would yield the general design of the appro 
priate MICS for the desired application. Of note is the 
fact that virtually all the literature encountered dealt 
with the private sector and as such emphasized the goals of 
the business enterprise and interactions with the market 
place. This orientation made it difficult to apply all the 
principles expressed to the Government perspective. 

The role of the SPO/NWC Manager was described briefly 
in Chapter I as one of performing the management functions 
of planning and controlling to assure the attainment of 
program goals and objectives. It was hypothesized that a 
comprehensive "system" was required in order to adequately 
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perform this role. A "system" is defined in Webster's 
Unabridged as "a complex unit formed of many often diverse 
parts subject to 'a common plan ox serving a common purpose . " 
It would appear obvious then that to design a system to 
serve a purpose, a concise definition of the purpose is 
essential. A concise definition of planning and control has 
been the center of arguments among authors of management 
texts for years. Particularly useful definitions of the 
planning and control functions for use in information sys- 
tems design, however, are expressed by Robert Anthony and G. 

A. - Gorry and M. S. Scott-Morton . 

B. CONCEPTUAL FRAMEWORKS FOR MICS 

1. Robert Anthony Framework for MICS 

In Planning and Control Systems ; A Framework for 
Analysis , Anthony addressed the problem of developing a 
classification scheme that would allow management some 
perspective when dealing in the area of planning and control 
systems. He developed a framework for analyzing these 
managerial functions or processes consisting of three cate- 

I 

gories and argued that the differences among these categor- 
ies were so significant that the systems designed for the 
processes would have substantially different characteristics. 

The first of Anthony's categories of managerial 
activities is "strategic planning." Strategic planning is 
defined as "the process of deciding on objectives of the 
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organization, on changes in these objectives, on the re- 
sources used to obtain these objectives, and on the policies 
that are to govern the acquisition, use and disposition of 
these resources. " [2] Anthony made a number of points with 
respect to strategic planning. First, it focuses on the 
choice of objectives for the organization and on the means 
required to achieve these objectives. As a result, problems 
in this area tend to involve longer range planning and 
therefore require prediction as to the future of both the 
organization and its environment. Secondly, the strategic 
planning process usually involves a small number of high- 
level people who must operate in a nonrepetitive and often 
very creative way. Thirdly, the types of decisions to be 
made involve many variables, and are usually unstructured 
and irregular. The results of these decisions are policies 
and precedents which are extremely difficult to evaluate. 

The second category defined by Anthony is manage- 
ment control. This process was defined as "... the process 
by which managers assure that resources are obtained and 
used effectively and efficiently in the accomplishment of 
the organization's objectives ."[ 2] He stresses three key 
aspects of this function. First, the process involves a 
larger number of persons; managers who must accomplish their 
tasks through interpersonal relations. Secondly, these 
tasks are defined within the context of objectives and 
policies that have been determined in the strategic planning 
process. Thirdly, the relevant criteria for evaluating the 
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actions taken are effectiveness and efficiency. 

Anthony's third category is operational control 
which he defines as "the process of assuming that specific 
tasks are carried out effectively and ef f iciently . " [ 2 ] The 
basic distinction between management control and operational 
control is that operational control is concerned with the 
execution of specified tasks, whereas management control 
deals with the whole stream of on-going activities rather 
than on specific tasks. Just as management control operates 
within policies established by strategic planning, so oper- 
ational control occurs within a set of procedures and rules 
that are derived from both management control and strategic 
planning. 

Anthony pointed out that the boundaries between 
these three categories are often not clear. In spite of 
their limitations and uncertainties, however, these categor- 
ies are useful in the analysis and design of information 
systems . 

2 . Gorry and Scott-Morton Framework 

G. Anthony Gorry and Michael S. Scott-Morton have 
also addressed the area of a conceptual framework for MIS. 

In a paper pioblished in the Sloan Management Review (Fall 
1971) they state that the purpose of their work is "... to 
present a framework that helps us to understand the evolu- 
tion of MIS activities within organizations . . . this frame- 
work is designed to be useful in planning for information 
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systems activities within an organization and for distin- 
guishing between the various model building activities, 
models, computer systems and so forth which are used for 
supporting different kinds of decisions ."[ 3] 

The Gorry and Scott-Morton framework is a two- 
dimensional framework which integrates the managerial func- 
tions as defined by Anthony with decision types as defined 
by H. A. Simon. In the New Science of Management Decision , 
Simon is concerned with the manner in which people solve 
problems regardless of their position within the organiza- 
tion. He makes the distinction between "programmed" and 
"nonprogrammed" decisions. Programmed decisions are defined 
as those which are repetitive and routine to the extent that 
a definite procedure has been established for handling them 
each and every time they occur. • Nonprogrammed decisions are 
those for which no "automatic" method for the decision 
making process has been established. They are by nature 
novel and nonrepetitive and therefore require individual 
action based on intelligent, adaptive problem solving. 

Gorry and Scott-Morton chose to use the terms 
"structured" and "unstructured" in lieu of programmed and 
unprogrammed in order to stress the basic concept of the 
problem-solving activity in question and avoid the implica- 
tion of computer dependence which might result from the use 
of Simon's terminology. They also included a class of 
decisions which they called "semi-structured." These deci- 
sions are characterized by the ability to structure a 
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portion of the decision making process but not the process 
in its entirety. 
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GORRY AND SCOTT-MORTON INFORMATION SYSTEMS FRAMEWORK (3) 

FIGURE II-l. 



A pictorial representation of the Gorry and Scott- 
Morton framework is presented in Figure II-l. While some 
examples are listed in each of the six cells, it is empha- 
sized that the cells are not well defined categories just as 
with the Anthony framework . The Gorry and Scott-Morton 
framework merges the two different perspectives of mana- 
gerial activity taken by Anthony and Simon. Anthony's 
categorization is based on the purpose of the management 
activity, while Simon's classification is based on the 
manner in which the manager deals with the problems which 
confront him. The combination of these two views provides a 
useful framework within which to examine the purposes and 
characteristics of information systems. 
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C. FRAMEWORK IMPLICATIONS ON THE MICS 

The characteristics of managerial activity defined by 
the Anthony and the Gorry and Scott-Morton frameworks have 
explicit implications on information systems de'sign in three 
general areas: information requirements, system character- 

istics, and the system design process. Implications in all 
three of these areas will be addressed here; however, only 
the information requirements considerations will be addres- 
sed in detail. The remaining two areas will be discussed at 
greater length in subsequent sections of this chapter. 

1. Information Requirements 

Clearly, there are many choices with regard to the 
characteristics of information presented to a decision maker 
or manager. The system designer must consider the use to 
which the information will be placed in deciding what infor- 
mation to provide. If the information requirements of the 
three categories presented by Anthony are considered, it can 
be seen that they are very different from one another. 
Further, this difference is not simply a matter of aggrega- 
tion from one level to the next but one of fundamental 
difference in the characteristics of the information needed 
by the managers in these areas". 

Strategic planning deals with broad policies and 
organizational objectives. Consequently, the relationship 
of the organization to its environment is a matter for 
consideration. Also, the nature of the activity is such 
that predictions of the future are required. Therefore, the 
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information needed by strategic planners is generally infor- 
mation from outside the organization and is based on esti- 
mates. It follows that this information is relatively 
imprecise and of an aggregate nature. Also, the nonroutine 
nature of the strategic planning process means that the 
demands for this information will be infrequent. 

The information needs for operational control are 
virtually opposite to those of strategic planning. Since 
this process deals with specific task accomplishment, it 
requires well defined and accurate information which is 
generated internally. This information must also be avail- 
able on a frequent basis and in greater detail. 

The management control process encompasses the 
totality of the organization and as such deals with some 
aspects of strategic planning and operational control. As a 
result, the information requirements of management control 
fall in between those of the other two processes. Anthony 
emphasizes that the information for the management control 
systems must be of an integrated nature, encompassing the 
varied and detailed requirements of the operational control 
system and the broad requirements of the strategic planning 
system. He suggests that the common denominator is money 
and, therefore, information in the management control system 
should be expressed in monetary terms. 

These general information characteristics and their 
relationship to the framework are illustrated in Table II-A. 
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This summary is subject to the same limitations and uncer- 
tainties which are applicable to the concepts of management 
control, strategic planning and operational control. How- 
ever, it does illustrate the contention that the inherent 
differences in the processes result in different information 
requirements . 
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INFORMATION REQUIREMENTS BY MANAGEMENT FUNCTION (3) 
TABLE I I -A. 

The degree to which the decision making process is 



structured or unstructured also has implications on the 
information required. If a decision process is structured 
to the extent that a model is in existence or can be con- 
structed, the model will identify what information is re- 
quired in very definite terms. If, however, the decision 
making process is unstructured, the information requirements 
will be ill-defined and the relevant information will re- 
quire identification on a case by case basis. 
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2 . System Characteristics 



In general terms, an information system collects 
source data and transforms or converts it into meaningful 
and useful forms. It is somewhat analogous to' the process 
of purchasing raw materials, producing finished goods, and 
distributing the finished products to customers. Drawing on 
this analogy, the system can be viewed as having three 
stages: inputs, processing and outputs. The manner in 

which these stages are accomplished is influenced by the 
needs of the user as characterized by his position in the 
framework. Therefore, the method of operation of the system 
and the system characteristics will in some respects be 
driven by these same considerations. 

For example, the input or data collection techni- 
ques appropriate for operational control would be dictated 
by the need for current information and frequent updating. 

An on-line computer terminal would fulfill these require- 
ments but would not be necessary for the input of data to a 
system designed for strategic planning. The basic differ- 
ences in the characteristics of the information required by 
the various cells in the frameworks indicate that quite 
different data base or storage arrangements are required to 
support the decisions encountered in each area. Strategic 
planning decisions require a data base with less accurate 
information which may be subjected to complex simulation 
models while operational control decisions require larger 
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amounts and more detailed information processed through less 
complex models. 

It can be seen that the frameworks provide a 
perspective from which to view information systems methods 
of operation and characteristics to determine the proper 
system to adequately fulfill the users' needs. A more 
detailed description of system characteristics which the 
user and system designer should consider in the design of a 
specific system will be presented in a subsequent section of 
this chapter. 

3 . System Design Process 

The implications of the frameworks on the design 
process are in the areas of the organizational level to be 
served, the types of models to be employed and the goals of 
the system under design. 

Individuals within an organization typically make 
different types of decisions depending upon their organiza- 
tional level. It would be rare to find first line super- 
visors involved in strategic planning, and conversely, the 
president or head of an organization should make relatively 
few operational decisions. Thus, if the level of management 
for which the system is to be designed is well identified, 
the Anthony framework is useful in presenting considerations 
to be made with respect to information requirements and 
system characteristics. The real point here is that the 
design of an information system depends heavily on the 
individuals who will use it. 
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The sources of models for operational control are 
niimerous. There is a history of applications, the problems 
are often similar across organizations and the systems are 
well documented. In strategic planning, and to a lesser 
extent management control, systems are still in the early 
stages of development. Models tend to be individual and are 
derived from the managers involved. It is a model creation 
process as opposed to a model application process. In 
general, it can be said that the information system's prob- 
lem in the structured area is basically one of implementing 
a given general model in a particular organizational con- 
text; however, work in the uinstructured areas is much more 
involved with model development and formalization. 

Gorry and Scott-Morton state that to improve the 
quality of decisions a systems designer can seek to improve 
the quality of the information inputs or to change the 
decision process, or both. [3] If an appropriate model is in 
existence, it would follow that better information would 
provide better decisions or control. However, in the case 
of an unstructured process the improved information may not 
be as fruitful (see ACKOFF [4]). This contrast implies that 
different design goals are appropriate for different appli- 
cations within the context of the framework. 

The goal of an information system in a structured 
setting is usually to improve the processing and quality of 
information. In unstructured situations the goal of the 
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information system may be primarily to improve the presenta- 
tion of information to the manager and to help in structur- 
ing the problem. 

The system design process will be dealt with more 
extensively in a subsequent portion of this chapter. Again, 
the perspective gained by the adoption of the framework will 
be helpful in addressing specific areas of system design to 
fulfill the particular users' requirements. 

D. INFORMATION SYSTEM CHARACTERISTICS AND CONSIDERATIONS 

The first section of this chapter dealt with the por- 
tion of the Webster definition of a system which included 
the "common purpose" for which an information system would 
be proposed and designed. The second section addressed some 
of the implications of the "common purpose" upon the system 
structure and characteristics. This section will expand 
upon those system physical characteristics which are in- 
cluded in the Webster definition as "a complex unit formed 
of many often diverse parts ..." and address the various 
considerations which must be undertaken in evaluating those 
physical characteristics with respect to a particular MICS 
design. 

1 . System Characteristics 

An information system was previously defined as a 
means of transforming or converting source data into meaning- 
ful and useful information. This transformation can be 
viewed from an operational perspective, i.e., what functions 
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or operations must be performed, and from a technical per- 
spective, i.e., through what methods these operations can be 
performed. 

a. System Operations 

While the exact sequence of operations required 
to convert particular items of data into information may 
vary to some extent, a general set of operations can be 
identified. Burch and Strater contend that these operations 
include capturing, verifying, classifying, arranging (sort- 
ing) , sximmarizing, calculating, storing, retrieving, repro- 
ducing, and disseminating/communicating . [5 ] A description 
of these operations and a grouping in terms of input, out- 
put, and processing is presented in Table II-B. 



INPUT 


CAPTURING 


RECORDING OF DATA FROM AN EVENT IN SOME FORM OF 
DOCUMENTATION 




VERIFYING 


VALIDATING THAT DATA WAS CAPTURED CORRECTLY 


PROCESSING 


CLASSIFYING 


PLACING DATA INTO SPECIFIC CATEGORIES WHICH 
PROVIDE MEANING TO THE USER 




ARRANGING 

(SORTING) 


PLACING DATA ELEMENTS IN A SPECIFIED SEQUENCE 




SUMMARIZING 


COMBINING OR AGGREGATING DATA ELEMENTS EITHER 
MATHEMATICALLY OR LOGICALLY 




CALCULATING 


COMPUTING OR OTHER ARITHMETIC AND/OR LOGICAL 
MANIPULATING OF THE DATA 




STORING 


PLACING DATA ONTO SOME STORAGE MEDIA FOR FUTURE 
RETRIEVAL 


OUTPUT 


RETRIEVING 


SEARCHING OUT AND GAINING ACCESS TO SPECIFIC DATA 
ELEMENTS FROM STORAGE 




REPRODUCING 


DUPLICATING DATA FROM ONE MEDIUM TO ANOTHER 




DISSEMINATING/ 

COMMUNICATING 


TRANSFERING DATA FROM ONE PLACE TO ANOTHER 



INFORMATION SYSTEMS OPERATIONS AND DESCRIPTIONS 
TABLE II-B 
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b. Systems Methods 

Advances in technology have resulted in many 
devices that can be utilized to perform the ten basic data 
operations as outlined by Burch and Strater. The informa- 
tion system in most large organizations is generally com- 
posed of a variety of technological and manual methods . 

Based on the level of automation represented, Burch and 
Strater presented four broad categories of data processing 
methods which they defined as (1) manual, (2) electromech- 
anical, (3) punched card equipment, and (4) electronic 
computer. 

In the manual method all of the data operations 
are performed by hand with the aid of basic devices such as 
pencil, paper, vis-boards, etc. The electromechanical 
method is actually a combination of man and machine. Ex- 
amples of this method would be an operator working at a tub 
file, calculator or duplicating machine. The punched card 
equipment method is sometimes referred to as the Electronic 
Accounting Machine (EAM) method. The principal recording 
medium is the punched card. A number of cards which contain 
data about a similar subject are grouped, together in a tray 
of cards usually termed a file. A typical punched card 
system is comprised of any or all of the following devices: 
key punch, verifier, sorter, collator, reproducer, account- 
ing machine, calculating punch, interpreter, and summary 
punch. It is worthy of note here that the recent advances 
in small computer technology are rapidly obsoleting punched 
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card equipment as a primary data processing method; however, 
many of these systems are still in existence. 

In general, the preceding methods utilize an 
individual, or a particular machine to perform each data 
operation separately. The development of the electronic 
computer allowed one machine to perform most of the data 
operations without intermittent human intervention. The 
electronic computer, as the term will be used in this 
thesis, means a configuration of input devices, a central 
processing unit (CPU) and output devices. There is a large 
variety of hardware available in a myriad of electronic 
computer system configurations. It is not the authors' 
intention to explore or describe these devices in detail but 
rather to point out their capabilities which warrant consid- 
eration in the development of a management information and 
control system application. 

The four methods of data processing which 
have been briefly described above are illustrated in Table 
II-C, along with their relationship to the data operations 
they perform. 

2 . Systems Considerations 

The old adage of "to get the right answers, you 
must ask the right questions" is particularly germane to the 
design of a MICS. In order to obtain a system which will 
satisfy the users' requirements, the user and designer must 
be able to translate the users' requirements into system 
capabilities. As pointed out previously, no specific model 
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Operation and methods of data processing. [5] 
TABLE II-C 



a 



for designing a MICS was discovered in the literature; 
however, a number of considerations in the accomplishment 
of an MICS design were presented by various authors. These 
considerations will be discussed from the viewpoint of the 
systems input, processing and output functions, 
a. Input Considerations 

The system input functions or operations are 
shown in Table II-B as capturing, initially recording and 
verifying the data to be entered into the system. An initial 
input consideration is the number and organizational level 
of the users of the system. How many people will actually 
require the ability to enter data? Who will actually enter 
the data? Will some data be sensitive and therefore require 
inputing from only designated people? What resources for 
data gathering and entering are currently in existence or 
are attainable? Does the user manager want to have the 
capability to enter data himself? 

The verification function brings forth two 
opposing viewpoints. One viewpoint is that a system which 
segregates the data collecting, recording, and entry func- 
tions will provide more chance for the detection of errors. 
The opposite viewpoint is that the more people or iterations 
involved, the greater the likelihood errors will occur and 
remain undetected. Both these viewpoints have merit and 
require consideration. 

The source of the input may have a significant 
impact on the requirement for verification. If an EAM 
or computer application is to be used, can the operator read 
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handwritten input data or must it be directly machinable? 

The application of this function to the system should be 
evaluated in light of the above as well as in the context of 
the conceptual framework previously discussed, i.e., the 
appropriate accuracy of the information required, 
b. Processing Considerations 

The processing functions as depicted in 
Tables II-B and II-C make up the majority of the system's 
operations. A primary consideration in the total system 
operation and in the processing functions in particular is 
time. The total system time and the processing time can be 
characterized in two ways: response time and frequency. 

Response time or turnaround time can be de- 
scribed as the measure of total time required to complete a 
cycle of the system. In the case of the processing func- 
tions, this would be the amount of time required to accom- 
plish the necessary processing operations appropriate for 
the data input and desired output. For the total system 
this would include the time required for the input functions 
and output functions as well as the time required by the 
processing functions. 

Frequency is the measure of how often the 
system cycle is completed. The consideration here is both 
in terms of user requirements and system capabilities. How 
often does the manager require the processing functions 
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performed? This will depend upon his position as depicted 
in the conceptual framework and the framework implied infor- 
mation requirements. The system capability for frequency of 
operation will be tied to the response time and the re- 
sources available to iterate the process. In general, both 
the response time and frequency capabilities of a system are 
improved with higher applications of automation given a 
reasonable' voltime of data to be manipulated. 

Another consideration relative to the process- 
ing functions is voliame. The quantity of data which must 
undergo the various operations must be determined. The 
number of categories to be used for the classifying opera- 
tion must be identified, and the amount and complexity of 
summarizing and calculating activity must be specified. The 
larger the volume of the processing operations the more 
resources, be it more people or more sophisticated equip- 
ment, which will be required to meet the users' demands. 

Storage and retrieval requirements must also be 
considered. The volume and detail of the files to be main- 
tained should be evaluated. If a computer based system is 
being considered, an estimate of how long the file data 
should be retained and the media for storage are important - 
file storage on computers is expensive. If the data can be 
printed and stored in file cabinets where only occasional 
access is necessary, it will cost far less than a computer 
direct access storage device (DASD) such as magnetic disc, 
drum, or data cell which would provide instantaneous access. 
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A trade-off must be made between hardware cost and slower 
access to data. 

There are two different approaches to the 
accomplishment of the processing functions in an electronic 
computer based system: batch processing and on-line proces- 

sing. Batch processing is characterized by a periodic 
(daily, weekly, monthly, or other convenient time frame) 
performance of the processing functions on the data accximu- 
lated over the prescribed interval. An on-line system 
processes each transaction as it occurs. Although these two 
approaches to the processing function tend to be mutually 
exclusive, there are examples of batched data transaction 
being input on on-line systems. 

There are practical differences between batch 
and on-line systems in a number of areas. Batch systems 
usually have separate data collection and preparation activ- 
ities such as keypunching source documents to punch cards , 
preparing magnetic tape from punch cards, record sorting, 
and so forth. On-line systems, on the other hand, usually 
collect data as transactions occur and transmit it directly 
to the computer without any intervening operations. 

Batch processing often involves reading the 
appropriate program into core storage and performing certain 
housekeeping activities before the data can be processed. 
Processor set-up activities are minimized in an on-line 
system since the system is actually maintained in a state of 
constant readiness. 
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In batch processing every single master record 
must be read into fast memory (core storage) for record key 
comparison with the current transaction record. If the 
number of transaction records is small, relative to the 
total number of records in the master file, processor effi- 
ciency may be rather poor. Under the same circumstances, 
on-line processing is more efficient since only the active 
master records are actually accessed. An additional consid- 
eration, however, is the problem of idle computer time when 
no transactions are entering an on-line system. Overall, 
batch processing makes somewhat more efficient use of pro- 
cessor capacity than on-line processing. 

Batch processing usually- requires fewer types 
and smaller capacity equipment than on-line systems. Remote 
terminals and auxiliary storage capacity are not necessarily 
required with batch systems, but are normally needed for on- 
line systems. The processor capacity of on-line systems may 
need to be larger in order to handle peak transaction activ- 
ity loads. Also, the computer operating control systems 
(software) for on-line system's tend to be more complex, 
expensive, and troublesome than that required for batch 
systems . 

On-line inquiry combined with off-line (batched) 
updating represents an intermediate state of complexity that 
can prove adequate in many instances. Here the data base is 
updated by conventional off-line processing and made avail- 
able for management inquiries during the working day with 
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the restriction that no updating occur during that time and 
with the day's transactions batched for entry in the 
evening. 

c. Output Considerations 

The considerations pertinent to the output 
functions of the system include a number of the same consid- 
erations 'set forth in terms of the other system functions. 

An acceptable timeframe in which to actually retrieve, 
reproduce and disseminate the required information must be 
defined by the user. The number and content of output 
reports must be addressed. Can the users' requirements be 
satisfied with a specific number of reports at prescribed 
intervals or is a free form interrogation of stored data 
required? These considerations will have a direct effect on 
the processing method of a computer system. The reports 
generated by a batch system are necessarily tied to the same 
cycle as that of the input and processing functions (e.g., 
daily, weekly, etc.). The manager is then tied to this 
schedule as well. 

The format of output reports should be addres- 
sed. Must the reports be hand copy or can quick- look cath- 
ode ray tube (CRT) displays suffice? If hard copy reports 
are needed, what will the physical requirements be in terms 
of size and format? Will charts or graphs need to be plot- 
ted or will output be in straightforward text? The volume 
of output reports required and their dissemination should 
also be included in the evaluation. 



The need for output security should be deter- 
mined. Will some of the output information be considered 
sensitive and therefore require restricted access? The 
methods of insuring this security will vary depending upon 
the type and design of the information system selected. 

While restriction of output data may be more difficult in an 
automated system than in a manual one, provisions can be 
made to preclude free access to certain outputs. 

E. THE INFORMATION SYSTEM DESIGN PROCESS 

Previously the authors indicated that the character- 
istics of the Anthony and the Gorry and Scott-Morton 
frameworks have explicit implications on the information 
system design in three general areas: information require- 

ments, system characteristics and the system design process. 
To this point, the system information requirements and 
system characteristics/capabilities have been discussed. 

This section will pursue the system design process itself. 

1. Definition of the Design Process 

The design process is what ties the managerial 
function of planning and control, information characteris- 
tics and requirements, and information systems' characteris- 
tics and capabilities together to produce a desired MICS. 
"Systems design can be defined as the drawing, planning, 
sketching, or arranging of many separate elements into a 
viable, unified whole. "[5] In a MICS this can be viewed as 
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the amalgamation of management functions and requirements 
with information systems capabilities. 

The Survey and Requirements’ phases of the MIS 
development cycle as outlined in Chapter One consists of a 
systems analysis which addresses the questions of what the 
system is doing and what it should be doing to meet user 
requirements. The systems design process is concerned with 
how the system is constructed to meet these requirements. 

The development cycle also shows that the design process is 
a long, sequential one which starts with a vary macro view- 
point in the requirements phase and gradually defines and 
refines the system requirements into a final form capable of 
implementation. 

2 . Design Approaches 

As indicated at the outset of this chapter, no 
specific model for the design of a MICS was found in the 
literature. The admission of the lack of a singular model 
is perhaps best illustrated by the description of the design 
process presented by Burch and Strater. They state that "in 
order to design a system the analyst must possess knowledge 
related to the following subjects: 1) organizational re- 

sources, 2) user information requirements, 3) other systems 
requirements, 4) methods of data processing, 5) data opera- 
tions, and 6) design tools. To produce a systems design, 
the analyst must apply reason and creativity to these ele- 
ments of knowledge. " [5] Figure II-2 provides a pictorial 
representation of this relationship. 
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AN ILLUSTRATION OF THE ELEMENTS COMPRISING THE DESIGN 
PROCESS FOR AN INFORMATION SYSTEM (5) 

FIGURE II-2. 

a. Burch and Strater Approach 

Burch and Strater do, however, outline some 



basic steps in their own approach to a design process. 

These steps include: 1) defining the system goal, 2) devel- 

oping a conceptual model, 3) applying organizational con- 
straints, 4) defining data processing activities, and 5) 
preparing the System Design Proposal. 



findings in the Survey and Requirements phases of systems 
analysis. The goal or goals need not be stated in specific 
informational requirements but rather in the purpose or 
desired result of the implementation of the system. 

Developing a conceptual model of the system is 
nothing more than a gross depiction of the inputs and de- 



Defining the system goal is a result of the 
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sired outputs of the system and the indication that some 
processing is required to effect thik conversion. 

Organizational constraints are defined in terms 
of resources available. These resources can take the form 
of manpower, machines, money, material or methods. Normally 
the information system must vie with other activities to 
obtain the necessary resources. This fact leads the manager 
and systems analyst to consider cost/effectiveness to the 
organization in the design and development of the system. 

In defining the data processing activities 
which the system requires Burch and Strater contend that you 
must begin with the identification of the desired outputs of 
the system. The next step is to list the specific informa- 
tion- fields required to prepare that output arid identify the 
specific input data required to develop those fields. Then 
the processing operations which will convert the inputs to 
the desired outputs must be addressed and defined. Having 
completed these steps for all desired outputs, the analyst 
should then consider the data base (file system and struc- 
ture) and control points necessary to support the outlined 
system design. 

Earlier, the point was made that the informa- 
tion needs of managers at different levels of the Anthony 
framework were very different from one another and that this 
difference was one of fundamental difference of characteris- 
tics, not just a matter of aggregation. This difference is 
reflected in the Burch and Strater design process of the 



system through the "tailoring" of the information system to 
the users' requirements. Burch and Strater present several 
specific methods for tailoring the information system to the 
requirements of an organization. These methods are useful 
regardless of the overall structure of the information 
system, and though presented individually, are also appli- 
cable in varying degrees of combinations to meet specific 
user requirements. 

Burch and Strater contend that the effective- 
ness of an information system can be improved by the follow- 
ing five basic methods: 1) filtering method, 2) monitoring 

method, 3) modeling method, 4) interrogative method, and 5) 
externa.1 method. The purpose of each of these methods is to 
provide the user the information required in the most effi- 
cient and effective way possible. 

The filtering method is based on the premise 
that various levels of decision makers require various 
levels of detail information as outlined in both the Anthony 
and Gorry and Scott-Morton frameworks. Ideally, the infor- 
mation system should be designed to permit the filtering of 
selected data elements from the data base so that each 
decision maker can obtain the level of detail appropriate to 
his or her individual needs. 

The monitoring method is another alternative 
for reducing the amount of data managers receive while still 
increasing the amount of relevant information at their 



48 



disposal. Instead of producing streams of data to be han- 
dled by the manager, the information system monitors the 
data and provides informational outputs to the user on a 
predetermined basis. The three basic ways to implement the 
monitoring method. are: 1) variance reporting, 2) programmed 

decision making, and 3) automatic notification. 

Variance reporting requires the establishment 
of normative values of performance and an acceptable amount 
of deviation (variance) from that norm. When the acceptable 
variance is exceeded the system automatically prepares a 
report to the responsible manager. 

Programmed decision making involves the use of 
the system to execute routing decisions based on predeter- 
mined check points or values. Only those items which exceed 
the parameters of the decision model would be referred to 
the manager for resolution. This method is most applicable 
to the structural, operational level of decisions as. depic- 
ted in the Gorry and Scott-Morton framework. 

The automatic notification method is used to 
take advantage of the vast memory capabilities of computors . 
The system merely monitors a large file of data and presents 
information on a predetermined basis. For example, a pri- 
oritized list of tasks to be accomplished can be input in 
the system, and as each task is completed the system will 
direct the user as to which task must be undertaken next. 

The modeling method utilizes various logico- 
mathematical models to transform data elements into desired 



information. They are used primarily to provide information 
of a predictive nature based upon the model parameters and 
the historical information furnished by 'the user. This 
method would normally be used by strategic planners and is 
constrained by the accuracy and capabilities of the model 
employed. 

The interrogative method relies on the user to 
format a specific inquiry to the system to meet a specific 
but previously unanticipated requirement. The system does 
not disseminate information until a specific request is 
received. While the concept here would allow for the ulti- 
mate in providing relevant data to the manager, the system 
requires an expensive investment in data processing re- 
sources and an extraordinarily large data base in order to 
respond to the unlimited or unstructured requests of the 
user. 

The external method refers to gathering infor- 
mation which is generated outside of the organization. As 
organizations become larger and more complex, the outside 
environment will .become of greater importance and external 
information has to be communicated in a formal manner rather 
than on occasional collections and observations of the 
managers themselves. This method is obviously directed 
toward the strategic decision maker, 
b. Wilkinson Approach 

Dr. Joseph W. Wilkinson outlines three differ- 
ent design approaches in his article "Classifying Information 
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Systems" which was published in the Journal of Systems 
Management, April, 1973. [6] Dr. Wilkinson contends that an 
information system may be simultaneously viewed as a data 
converter, a decision-oriented network, and a data base. 
These three views correspond respectively to what he terms 
"the three phases in the evolution of information system 
design" which has occurred over the past twen‘^:y years. 

These three phases are: 1) designing efficient operating 

systems, 2) designing output-oriented scheduled reporting 
systems, and 3) designing input-oriented demand reporting 
systems . 

These three perspectives and corresponding 
design approaches appear to fit well within the Anthony and 
the Gorry and Scott-Morton frameworks . The perspective of 
the system as a data converter corresponds to the focus upon 
designing information systems in support of the operational 
level where the objective is to provide efficient data 
conversion operations within Well-defined bounds. The 
particular activity which this type of MIS is to serve is 
normally a structured one and therefore the design process 
becomes one of merely specifying the data collection, data 
processing and output data communication operations as 
dictated by the structure. 

The perspective of the decision-oriented net- 
work appears to correspond with Gorry and Scott-MOrton ' s 
categories of structured or semi-structured management con- 
trol. This decision-oriented network viewpoint emphasizes 
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the regularly recurring flows of data and information 
between the operational level and the decision-making level 
which enable the managers to make planning and control 
decisions. The design process as described by Wilkinson in 
this decision-oriented network perspective is an output- 
oriented approach in which the initial effort is devoted to 
determining what information is needed by whom, how often it 
is needed, etc. When the characteristics of the needed 
information are fully specified the system designers work 
backwards to specify the input data and conversion processes 
necessary to provide that information". A basic assumption 
underlying this approach is that regularly scheduled reports 
can provide managers with the information they need for 
successful completion of most of their responsibilities. 

The data base perspective emphasizes "the col- 
lecting and organizing of data for use by managers in de- 
cision making in an unpredictable environment. This outlook 
can be interpreted as the unstructured managerial control 
level or the strategic planning level. The input-oriented 
design approach which Wilkinson contends is necessary to 
support this perspective concentrates on data collection and 
storage for random retrieval. The assumption underlying 
"tdiis approach is that "the environment of the manager is so 
dynamic that he cannot know in advance what decisions must 
be made and therefore he cannot determine and specify much 
of the information he needs. Consequently, the design 
approach is to select and organize for easy retrieval a 
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massive variety of data that has some probability of being 
needed. As the manager encounters an unexpected decision, 
the system provides the requested information promptly in a 
flexible reporting format. 

3 . Summary 

The use of the above design approaches will aid 
the information system designer in bridging the gap between 
user requirements and system definition. By highlighting 
the users' perspective and relevant information needs and 
relating them to a method or combination of methods for 
providing that information the designer will begin to define 
the system capability requirements in terms of system consid- 
erations and system characteristics. 

F. CRITERIA FOR SELECTION OF SYSTEM TYPE 

A MICS can be designed which will meet the users' 
requirements in a variety of ways as shown in the previous 
section. Furthermore, the system design can be specified 
without stipulation of the data processing method in most 
cases. How then do the user and system designer decide upon 
the proper method for a particular application? 

Burch and Strater contend that this selection requires 
consideration of both processing requirements of the system 
and performance capabilities of each processing method. The 
processing requirements can be viewed as being determined 
by: 1) the volume of data elements involved, 2) the com - 

plexity of the required data processing operations. 
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3) processing time constraints, and 4) computational demands. 
As in other aspects of the MICS design and development, no 
specific model exists to determine the exact degree or level 
of these requirements which corresponds to a given process- 
ing method. However, it can be stated in general that as 
the volume of data increases, as complexity increases, as 
time constraints become more severe, and as computational 
demands become more sophisticated, an increased level of 
automation is warranted. Not all these conditions need be 
present. It may be that a single processing requirement is 
so dominant that an advanced level of automation is war- 
ranted on that parameter alone. 



Data 

Processing 

^\Method 

Factors 
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Computer 


Initial Investment 
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High 


Set Up 
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Moderately low 


Moderately high 
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Conversion 
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High 
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Moderately low 
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Modularity 
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Flexibility 
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Versatility 
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Processing Speed 
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Computational Power 
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Processing Control 
Automatic Error 


Low 
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Detection 
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Medium 
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High 


Decision Making 


Moderately low 
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Level of Degradation 
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Moderately low 


Medium 


High 


Level of Automation 


Low 


Moderately low 


Medium 


High 



Comparison of the four data processing methods [5] 
against fifteen basic performance factors. 



TABLE II-D. 

Performance capabilities are equally important in the 
consideration of a specific selection. While there are many 
dimensions of data processing to consider, Burch and Strater 
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outline fifteen basic factors. These factors are compared 
for each of the previously identified methods of data pro- 
cessing in Table II-D. 

The real deciding factor in the selection process, 
however, may be economic. The user could choose the most 
sophisticated electronic computer system available to 
accomplish the simplest processing requirement if he wanted 
to pay for it. On the other hand, the user might have a 
legitimate requirement for that same system based upon the 
preceding criteria but be forced to tradeoff some of the 
system's capabilities in light of available resources. 

If an electronic computer system is deemed appropriate 
for the users' requirements a further selection must be made 
among- on-line processing, batch processing, or some combin- 
ation of the two. In Information System Analysis ; Theory 
and Applications , M. J. Alexander presents three factors 
pertinent to that decision: 1) cost, 2) quality, and 3) 

timeliness. Batch systems tend to be less costly per trans- 
action because of more continuous use of the computer and 
reduced hardware/software requirements as discussed in a 
previous section. Alexander contends that batch systems 
have fewer errors since it is difficult to check on-line 
systems for accuracy. This evaluation is the basis for some 
debate, as stated previously. On-line systems can provide 
more current information than batch systems due to the basic 
nature of the operation. If timeliness is crucial to the 
operation, an on-line system is dictated. However, if 
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timeliness is not that crucial a batch system or combination 
of batch and on-line inquiry as previously discussed are 
viable options. 

G . SUMMARY 

This chapter has discussed current literature view- 
points in the areas of planning, control, and MICS. Con- 
cepts in the general areas of system information require- 
ments, characteristics, design processes, and selection 
criteria were presented in order to give the reader a perspec- 
tive from which to examine and evaluate the MICS situation 
and requirements of the SPO/NWC. The subsequent chapters of 
the thesis will deal with application of the Survey, Require- 
ments, and Preliminary Design Phases of the Rigo MIS develop- 
ment model to the SPO/NWC. 
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III. CURRENT SPO/NWC OPERATION SURVEY 



A. BACKGROUND 

The methodology adopted for this thesis research calls 
for a survey phase to investigate the current situation 
thoroughly and systematically in order to answer the key 
questions "what are the facts" and "what is the real pro- 
blem?". The literature points out that there are both 
advantages and disadvantages to studying the existing sys- 
tems. The primary disadvantages of analyzing the existing 
system are that it is expensive in terms of time and re- 
sources, and that it may introduce unnecessary barriers or 
biases in the development of subsequent systems. 

There are four advantages in analyzing the present 
system. First, the current System may not require replace- 
ment in total. Minor modification may result in satisfying 
the information and control needs of the user. Secondly, 
investigation of the current system will reveal specific 
areas which need improvement and point out problem areas 
which must be dealt with if the development of a new system 
is necessary. Thirdly, analysis of the current situation 
will provide data on the volume, sources, and character- 
istics of information required. Finally, analyzing the 
existing system can provide an immediate source of design 
ideas for the new system. Dr. Donald F. Heany, the author 
of Development of Information Systems , states that "de- 
signers say they discover the clues they need to satisfy the 



57 



proposed information requirement (during the course of 
analyzing the existing system) . They do not know how this 
happens, merely that it does happen. ''[7] 

For the above reasons, the authors have chosen to study 
the existing SPO/NWC organization and the information sys- 
tems utilized. The investigation of the current situation 
at SPO/NWC is presented in this chapter and entails discus- 
sion in the areas of (1) organizational relationships, (2) 
roles and responsibilities, and (3) current management 
information and control systems . 

B. ORGANIZATIONAL RELATIONSHIPS 
1. Naval Air Systems Command 

NAVAIR is one of six subordinate commands of the 
Navy Material Command. The NAVAIR organization follows a 
concept employing functional and product organizations with 
line and staff organizational structures. Appendix A de- 
picts the NAVAIR organizational structure. In addition, 
program management organizations are superimposed on the 
basic functional organization for prosecution of selected 
priority projects. PMA-259 is one of the NAVAIR selected 
priority projects. 

The NAVAIR functional organization personnel are 
used to accomplish the program objectives established by 
PMA-259. These functional organizations provide the funda- 
mental skills and disciplines required to support the NAVAIR 
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mission. These organizations are utilized by each NAVAIR 
program for basic technical and administrative support. 

The interface on the Sidewinder Program between 
NAVAIR and NWC is PMA-259 and the SPO/NWC, as these two 
organizations have been delegated Sidewinder Program respon- 
sibility by their respective commands. Appendix B shows the 
NAVAIR functional organizations which support the Infrared 
Missile Program Office and their program relationship to - 
PMA-259 and SPO/NWC. Of note is the number and diversity of 
functional disciplines/codes which furnish support to PMA- 
259 and the fact that these codes do not have line responsi- 
bility to PMA-259. 

2 . Naval Weapons Center 

NWC is a major Naval Laboratory under the direction 
of the CNM. NWC is organized along functional lines and the 
SPO/NWC is located in the Engineering Design Division of the 
Engineering Department, as illustrated in Appendix C. It is 
of interest to note that the relationship of the SPO/NWC to 
NWC and the Engineering Department places the SPO/NWC within 
the functional line organization. This type of organization 
differs from the classic matrix organizational structure in 
which the SPO/NWC Manager would be external to the line 
functions and would occupy a position within the organiza- 
tion at the department or equivalent level. This more 
conventional matrix organizational relationship is illus- 
trated by the PMA-259 /NAVAIR organizational relationship. 
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The Engineering Department at NWC, as depicted in 
Appendix D, is staffed and organized to provide the techni- 
cal disciplines required in the acquisition of a major 
weapons system. The technical functions of each division 
are shown in Table III-A. 

Each of the technical divisions, and particularly 
the branches within each division, has a program interface 
with the SPO/NWC as depicted in Appendix E. 

Appendix E details the functional and Sidewinder 
program lines of responsibility and authority within the NWC 
organization. As shown, the SPO/NWC has program management 
interface not only with branches within the Engineering 
Department but with functional branches in other depart- 
ments. Examination of Appendix E indicates the magnitude, 
complexity, and diversity of the organizational relation- 
ships that exist between the SPO/NWC and the functional 
divisions/branches which result from the application of the 
program manager concept. As previously noted, the SPO/NWC 
is organizationally located at the branch level, and this 
fact increases the management planning and control function 
difficulties inherent within a program manager/functional 
organization relationship. 

3 . SPO/NWC Organization 

The SPO/NTVC is organized to support the production, 
development, test, and integrated logistic support (ILS) 
functions of the program. The fiscal, clerical, business, 
and data functions are performed by a staff organization in 
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NAVAL WEAPONS CENTER DIVISIONS TECHNICAL FUNCTIONS 



support of the major program functions. These relationships 
are shown in the organizational chart of the SPO/NWC as pre- 
sented in Appendix F. 

There are sixteen employees in the SPO/NWC organi- 
zation. The fiscal and data functions are . performed by 
personnel who are assigned to the office from other func- 
tional codes on a full time basis. The four functional 
managers are supported by project engineers who’ have respon- 
sibility for various components of the missile system; i.e.. 
Guidance and Control Section (GCS) , Active Optical Target 
Detector (AOTD) , etc. 

4 . Participating Field Activities (PFAs) 

The SPO/NWC has program interfaces with other Navy 
and Air Force activities. Appendix G lists the primary 
support activities with which -the SPO/NWC maintains an 
interface and indicates the principal area of support pro- 
vided by these activities. The coordination and liaison 
with these activities is required to fulfill the SPO/NWC 
management responsibilities for which technical expertise is 
not available within NWC itself. 

i 

5 . Sidewinder Missile Component Contractors 

One of the SPO/NWC responsibilities is to assist 
NAVAIR in the resolution of production problems . This role 
requires interface with companies who have hardware con- 
tracts for Sidewinder components. Appendix H lists the 
major component contractors and the components manufactured, 
with whom SPO/NWC maintains an interface. 
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C. RESPONSIBILITIES/TASKS AND INFORMATION FLOW 

1. Description of Responsibilities and Tasks 

The SPO/NWC responsibility is delegated to the 
SPO/NWC via the Commander, NWC, through the line organiza- 
tions (see Appendix C) . These responsibilities flow from 
two distinct sources, i.e., the program responsibilities as 
defined in AIRTASKS and Work Unit Assignments and the NWC 
organization responsibilities as defined in NWC and Engi- 
neering Department instructions and policies .[ 8&9 ] 

The SPO/NWC Manager, as head of the SPO/NWC, oper- 
ates under the Sidewinder (AIM-9) Program Management Plan. 
The responsibilities as defined in the plan are: a) The 

overall missile system coordination function between NAVAIR 
sponsoring activities/co-sponsoring USAF activities/foreign 
country users and NWC, b) the overall missile system coor- 
dination function (as delegated by NAVAIR between the sup- 
porting field activities and NWC, c) the overall missile 
system coordination function (as delegated by NAVAIR between 
the primary and/or secondary source contractors for missile 
system hardware and NWC, d) the overall missile system 
coordination function between NWC suppprting contractors or 
field activities and NWC, and e) the overall missile system 
coordination function between the SPO/NWC and the NWC sup- 
porting/participating codes. 

To carry out his assigned responsibilities, the 
SPO/NWC Manager performs or directs the performance of the 
following: a) establishment, structuring, and supervision 
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of the SPO/NWC to carry out its assigned/delegated func- 
tions, b) acquisition and/or assignment of SPO/NWC staff 
members to perform assigned tasks in accordance with the 
established organizational and functional charts, c) estab- 
lishment of policy and procedure guidelines for carrying out 
these assigned/delegated functions, d) preparation and/or 
implementation of task assignments to be performed together 
with the responsibility and authority assigned (including 
the determination of the in-house/of f-Center structure) , e) 
establishment and/or implementation of planning and control 
procedures for monitoring the progress of accomplishments, 
f) establishment and/or implementation of reporting proce- 
dures as required for off-Center sponsoring activities and 
NWC, g) preparation and presentation of program material/ 
briefings for off-Center sponsors and other Department of 
Defense official visitors, and h) establishment and mainte- 
nance of a permanent file for all program related informa- 
tion. 

In summary, the basic responsibility of the SPO/NWC 

Manager is one of managing an organization with policies , 

/ 

planning and control techniques to perform the tasks/func- 
tions required to support the Sidewinder Program. 

As shown in Appendix F, the SPO/NWC is organized to 
support the functional requirements of the AIM-9 series 
missile, i.e., development, test, ILS, and production. 

Using the SPO/NWC organization as the basis. Figure III-l 
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depicts the decision levels used by the SPO/NWC Manager to 
fulfill the assigned responsibilities. 



ORGANIZATION 


RESPONSIBILITY 


PROGRAM MANAGER 


POLICY AND PROCEDURE GUIDELINES 


PRODUCTION MANAGER 


POLICY AND PROCEDURE IMPLEMENTATION 


PROJECT ENGINEERS: 

O GCS 
O AOTD 

OAFT COMPONENTS 
O EXPLOSIVE COMPONENTS 


OPERATIONAL 



DECISION LEVEL DIAGRAM-SPO/NWC 
FIGURE III-l 



Figures III-2, III-3, and III-4 are functional 
charts which depict the functional areas, elements, and 
items for which the Production Manager has been delegated 
responsibility. The Production Manager has the responsibil- 
ity to coordinate with each Project Engineer to ensure that 
the production engineering, production monitoring, and 
fiscal accountability areas are addressed within the Project 
Engineer's areas of responsibility. The Project Engineers 
have the responsibility for one or a series of missile 
components as illustrated in Figure III-l. Each Project 
Engineer is responsible for accomplishment of all tasks 
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PRODUCTION MANAGER RESPONSIBILITIES - FUNCTIONAL CHART NO. 

FIGURE m-2 
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PRODUCTION MANAGER RESPONSIBILITIES - FUNCTIONAL CHART NO 

FIGURE ni-3 
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PRODUCTION MANAGER RESPONSIBILITIES- FUNCTIONAL CHART NO. 

FIGURE HI-4 



relating to his missile components in each of the functional 
areas of production monitoring and production engineering. 

The budget, funding, and cost control/reporting 
elements, as shown on Figure III-4, are accomplished through 
a series of procedures performed by SPO/NWC staff personnel. 
However, the Project Engineers have the responsibility of 
monitoring actual costs versus planned expenditures . The 
primary responsibility of the production manager in the area 
of fiscal accountability is the establishment of job orders 
(JOs) under NWC fiscal guidelines. 

The SPO/NWC AIM-9L production support responsibili- 
ties are defined through the AIRTASKS and Work Unit Assign- 
ments presented in Appendix I. These responsibilities are 
outlined in very general terms. Specific tasks are identi- 
fied on an "as required" basis to support a specific con- 
tract. A similar situation exists with the SPO/NWC person- 
nel's responsibilities, i.e., responsibilities are defined 
in general terms in personnel descriptions and through 
organization charts. Detailed tasks are assigned on an "as 
required" basis. 

2 . Assignment of Tasks and Information Flow 

To this point, the discussion of the SPO/NWC opera- 
tion has highlighted the organizational relationship, func- 
tions, and responsibilities of the organization and person- 
nel in the AIM-9L production support effort. This section 
will identify how the previously mentioned detail tasks are 
received and assigned, the nature of these detail tasks, and 
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what kind of information requirements, characteristics, and 
interfaces are associated with these tasks. 

The detailed tasks received by the SPO/NWC are as 
numerous and diverse as the previous discussions would 
indicate. They are received from any and all organizations 
discussed previously and take the form of phone calls, 
messages, letters, etc. In order to quantify the volume and 
form of these requests for task accomplishments , the authors 
collected data from correspondence files. In addition, the 
SPO/NWC Manager, the Production Manager and the CCS Project 
Engineer maintained logs of incoming requests for a period 
of twenty working days. The raw data and assumptions used 
to arrive at the voliame and type data shown in Table III-B 
are contained in Appendix J. The data presented in Table 
III-B illustrates the volume, data form and organizational 
level of the information flow. This data will be used to 
assess the needed MICS characteristics and capabilities in 
the next chapter. 

The characteristics of information received by each 
member of the office to fulfill his responsibilities is 
different. The difference is primarily in the level of 
detail and scope of information required for the decision 
making process, i.e., the Project Engineer is involved with 
many detail facts on one component of the Sidewinder mis- 
sile, the Production Manager is involved with production 
problems encompassing all the components of the Sidewinder 
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missile, the SPO/NWC Manager is involved with summarized 
facts for all functions of the program. 

The flow of information (who receives/who requests) 
is also different. The Project Engineers' primary contacts 
are with the NAVAIR technical codes, contractor technical 
engineers, and NWC technical personnel and production mana- 
gers. The Production Manager's primary contacts are with 
the NAVAIR Assistant Project Manager, NWC branch heads, and 
contractor program personnel. The SPO/NWC Manager's primary 
contacts are the NAVAIR Project Manager, other DoD Program 
personnel, NWC division and department heads. 

Figure III-5 represents an information flow anal- 
ysis from and to the SPO/NWC. For purposes of this study, 
only one Project Engineer is addressed. The other Project 
Engineers would have similar interfaces with applicable 
NAVAIR and NWC technical codes. The type and content of 
tasks and information flow for other Project Engineers would 
be similar. The different individuals and organizations 
that interface with the SPO/NWC personnel are noted. The 
solid and dash lines represent information flow into and out 
of the SPO/NWC, respectively. This analysis is helpful in 
showing the multiple informational interfaces at each level 
and the multidimensional aspects of the information flow. 

The assignment of tasks within the SPO/NWC organi- 
zation can be described as a structured or programmed 
decision-making process. The requests for task accomplish- 
ment are directed to the cognizant functional area and/or 
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Project Engineer by the application of a predetermined area 
of responsibility guide. Distribution of incoming corre- 
spondence is made from a standard distribution list which 
relates subject to cognizant personnel, i.e., the Project 
Engineer (GCG) receives a copy of all correspondence relat- 
ing to the GCG, the Production Manager receives a copy of 
all production related items, and the SPO/NWC Manager re- 
ceives a copy of all correspondence. The Data/Configuration 
Manager (D/CM) receives all correspondence related to data 
(ECPs, contract data items, etc.) It is then the responsi- 
bility of each individual to take action on items (tasks) 
relating to their area of responsibility. 

Examples of the process would be: 1) the D/CM 

receives all ECPs and starts them into the configuration 
control process, and 2) the Project Engineer receives a 
request for a specific task accomplishment and then proces- 
ses action items by a formal task agreement or verbal ar- 
rangement with the functional codes, depending on funding 
requirements and scheduled time span. It is significant to 
note that the programmed method of task assignment within 
the SPO/NWC does not record these specific arrangements in 
any formal system. Sometimes a "tickler" copy of an action 
document which has been assigned to a particular Project 
Engineer is retained, or a note is made in the SPO/NWC 
Manager's notebook, but no formal record is kept on all 
assignments. Formal systems do exist to control and track 
certain items, such as ECPs and contract data items. These 
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systems will be discussed in the following section of the 
thesis . 

The assignment of tasks by the SPO/NWC personnel to 
the NWC functional organization is accomplished through a 
task agreement system as indicated above. Each functional 
code which supports the SPO/NWC is issued a task agreement 
which defines the scope of work, funding required, and 
schedule anticipated for a given fiscal year. The Produc- 
tion Manager, Project Engineer,' and SPO/NWC Manager as a 
team write these task agreements as a part of the yearly 
budget process. Task assignments are made within these task 
agreements in response to specific requests for work or 
information received by the SPO/NWC. The major tasks of the 
Project Engineer are to determine the progress of specific 
detail tasks against a general task agreement and meet 
program commitments. The Project Engineer has the responsi- 
bility to monitor the task progress on a continuing basis 
through personal contact and weekly fiscal reports. Addi- 
tional task agreements are written for special efforts not 
anticipated at the start of the fiscal year, and where the 
funding requirement is greater than twenty-five thousand 
dollars. All these task agreements are in essence a formal 
contract between the SPO/NWC and each of the functional 
codes. Information flow among all the participants, as 
shown in Figure III-5, takes many forms. In addition to the 
"as required" communication flows previously discussed, 
there exists a requirement for formal periodic reports to 
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NAVAIR and NWC management from the SPO/NWC . These reports 
are to provide the overall program progress in terms of 
cost, schedule, and performance which is required for man- 
agement decision making. A detailed discussion of these 
reports and the system for their generation will be under- 
taken in the next section. 

D. CURRENT CONTROL AND INFORMATION SYSTEMS 

A single integrated MICS does not currently exist 
within the SPO/NWC. Rather, the existing system is made up 
of a number of disjointed systems designed to perform infor- 
mation and control functions in specific areas. These 
systems include the Correspondence Filing and Distribution 
System, Funding Control System, Task Agreement System, Mark 
III Management System, Data/Configuration Management System, 
Periodic Reports System, and Program Review Action Item 
system. This section will discuss each of these systems 
individually to gain an appreciation for their purpose, 
functions and effectiveness. 

1 . Correspondence, Filing and Distribution 

The correspondence and filing system in the SPO/NWC 
is designed to log, distribute and file each item of corre- 
spondence which is transmitted from or received by the 
office. Correspondence as used herein is either a letter, 
message, transmittal receipt, speedletter or memorandum. 

The system functions are performed by a civilian contractor 
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and utilizes the contractor person fulltime. The annual 
cost to the SPO/NWC is $24,000. 

Figure III-6 depicts the steps which each item of 
correspondence follows through the system. The log entries 
and semi-annual listing contain the microfilm ID number, 
the date of the document, the type of correspondence, the 
originator file number, the originator's code or organiza- 
tion, the correspondence serial or registration number, the 
addressee name or code, the subject of the correspondence, 
and the title of any enclosures. Approximately a one day 
turn-around time is involved in the distribution, microfilm 
and file processes. The keypunching is not done on a 
regular basis. The sorting of the card deck file and pro- 
duction of the file number sequence listing is done semi- 
annually. The file copy is maintained in the SPO/NT^C files 
for two years; after this time it is packaged, transferred 
to a federal storage facility, and stored indefinitely. The 
developing of the microfilm is done monthly and the micro- 
film cartridges are retained in the SPO/NWC. 

The system is basically designed to provide a 
permanent record of all SPO/NWC correspondence. With the 
date and originator, any item of correspondence can be 
retrieved from the file system. 

2 . Funding Control Process 

The description of the funding control process is 
limited to the interaction of the SPO/NWC and the NWC 
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CORRESPONDENCE FILING AND DISTRIBUTION SYSTEM FLOW DIAGRAM 

FIGURE m-6 



Comptroller (Code 08) financial system and therefore does 
not include the Code 08 processing procedures. The SPO/NWC 
budget as submitted to PMA-259 (sponsor) is the basis for 
the funding received by NWC for the Sidewinder production 
support effort. 

The funding system, as depicted in Figure III-7, is 
used to report, bill, and track the funding from sponsors 
for all NWC projects and programs. The SPO/NWC production 
support funding is identified through the NWC financial 
system by a seven digit customer order number. The customer 
order identifies the funds to the Engineering Department, 
the Sidewinder production support effort, and the fiscal 
year the funding was appropriated. Added to the customer 
order are three letters which define the job order (JO) . 
Unique JO letters are established by the SPO/NWC Production 
Manager for each task agreement entered into with the func- 
tional codes. The JO letters are the means by which the 
SPO/NWC identify, track, and control the internal expendi- 
tures versus task agreement allocations . 

As noted in Figure III-7, there are two processes 
involved; one is the NWC Code 08 financial system, which has 
the control of all financial processing and two, the SPO/NWC 
JO system which establishes the JO and task agreement from 
which the functional codes derive the assets to pay sal- 
aries, purchase material, etc. 

Funding documents, i.e., AIRTASK, MIPR, etc., are 
received by Code 08 and enter the financial system. Then 
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SPO/NWC, Engineering Design Division, and Engineering Depart 
ment review the documents for acceptance or rejection. Once 
the funding is accepted, a planned budget with JOs is submit 
ted to Code 08. This budget establishes the planning data 
required by NWC management for the funds received. The 
budgets are prepared by the Production Manager and Project 
Engineers based on projected task inputs from each of the 
functional codes involved in the particular task agreement. 
Format, overall policy and content are reviewed by the 
SPO/NWC financial assistant and SPO/NWC Manager before 
release. The budget documents are also signed by the divi- 
sion and department offices. 

Once the funding documents are received, approved, 
and budgets prepared, the functional codes can use the 
funding for the performance of specific tasks. As task 
assignments are accomplished by the functional codes , the 
applicable customer order and JO are cited on timecards, 
requisitions, and other expenditure documents. The SPO/NWC 
is not involved in the functional codes timecard payroll 
process but does approve all other expenditure documents. 

Once the charges are made against the particular 
customer order and JO, a report is generated which details 
all charges. This report is received on a weekly basis and 
is used by Project Engineers and Production Manager to track 
funds expended against various task agreements. The monthly 
summary is used by the SPO/NWC Manager to track expenditures 



81 



against budgeted amounts. The monthly summary is also sent 
to PMA-259 as a portion of the SPO/NWC monthly report. 

3 . Task Agreement Process 

The SPO/NWC depends on the functional organization 
for the support necessary to fulfill the Sidewinder AIM-9 
responsibility at NWC. To define the support requirements 
between the SPO/NWC and the functional codes , formal task 
agreements are established. The task agreements are the 
principal formal program link between the SPO/NWC and the 
functional code. 

The task agreements are typically general in nature 
and define the description of work, the approach to be 
taken, and the estimated funding by customer order and 
unique JO. Appendix K is an example of a typical task 
agreement. As seen in the example, the approach is general 
and the period of performance (schedule) is continuing for 
one year. 

The task agreements usually are established on the 
fiscal year and follow the budget cycle, although task 
agreements are established for special tasks when the esti- 
mated cost is over twenty-five thousand dollars. 

Any particular detail tasks then remain to be 
defined and assigned in meetings, memoranda or telephone 
calls between the Project Engineers and the functional 
organization. 

In summary, the task agreements perform the fol- 
lowing functions: a) define the general resource level 
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required from the functional code, b) define the general 
description of work and approach, c) define the funding 
level for the functional organization with unique JOs, d) 
define the reporting requirements, and e) define the general 
schedule . 

4 . Mark III Management System . 

The Mark III Management system is used within the 
SPO/NWC to visually display the .Sidewinder component con- 
tracts' Master Data Program Schedules. The Mark III Manage- 
ment system is a computer based management system with two 
basic outputs available to the user: 1) direct outputs from 

the computer, and 2) outputs resulting from computer gener- 
ated plots. 

The direct outputs, i.e, listing of planning 
updates, listing of safety paths, etc., are not used in the 
Sidewinder Production Support effort and will not be dis- 
cussed. The computer generated plot is used for tracking 
contract data items (GDI) in the AIM-9L Production Support 
area. Contract data items are primarily reports and plans 
required to be delivered by the contractor at prescribed 
times or intervals in accordance with the contract. These 
reports and plans (referred to as contract data items) are 
reviewed by NWC to insure compliance with the contract and 
technical worth. 

The computer generated plot is basically a planned 
schedule. The plots are available in three different forms: 
1) detail, 2) selective, and 3) summarization. For contract 
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data items, the summarization form is used. The plots, one 
for each contract, give the activity (data item) , respon- 
sible Project Engineer, and item delivery schedule for each 
data item. Figure III-8 is a block diagram of the flow of 
a data item when received by the SPO/NWC. 

The data plots are used as a visual representation 
of the contract data item delivery dates. The incoming 
contract data items are checked against the contract re- 
quirements by a data clerk, and are routed to functional 
codes with a response date assigned by the Data Manager and 
Project Engineer. The data clerk tracks the response dates 
and compiles review notes. The Data Manager and/or Project 
Engineer then write a letter response as required in the 
specific contract. 

5 . Data/Configuration Management System 

The configuration management responsibility within 
the SPO/NWC requires evaluation of Engineering Change Pro- 
posals (ECPs) , establishment of product baselines, establish- 
ment and maintenance of a master documentation control 
center, and establishment of configuration management prac- 
tices . 

Plans to define data/configuration management 
practices and policies within NWC are contained in the 
Document Control Plan for the Sidewinder AIM-9H/L missile 
(TN 5551-1-75) . The bulk of the configuration management 
effort is in the processing of ECPs required to control, 
change, and maintain the product baseline. The product 
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CONTRACT DATA ITEM FLOW DIAGRAM 
FIGURE m-8 
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baseline includes all drawings and specifications used to 
define the AIM-9L missile. To illustrate the process in- 
volved in changing the product baseline, a flow diagram, which 
includes the contractor and Defense Contract Administration 
Service (DCAS) organization's role along with process time 
requirements, is shown in Appendix L. As illustrated, 
twenty steps are performed by the SPO/NWC Project Engineer, 
D/CM, Configuration Accounting personnel and appropriate 
functional codes upon receipt of an ECP by the SPO/NWC. 

These actions require about 20 working days to accomplish. 

The SPO/NWC receives anywhere from 20 to 50 Class II ECPs a 
month which are processed within the SPO/NWC by the D/CM and 
two data clerks. 

Processes similar to those shown in Appendix L 
are required for a Class I ECP with the exception that 
NAVAIR has final approval/ disapproval authority. Once 
production deliveries have started; however, only four to 
five Class I ECPs are received each month so they have a 
small impact on the overall workload. 

6 . Periodic Reports 

There are four formal periodic reports required 
from the SPO/NWC in conjunction with the AIM-9L Production 
Support effort. The NAVAIR program status report and the 
visit action report are each required on a monthly basis. 
Reports to NWC management consist of the NWC Management 
Program Status Report (monthly) , and the NWC Weekly Program 
Highlight Report. 
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The monthly NAVAIR report, the most comprehensive 
of the reports, includes a detailed technical status of each 
functional discipline of the program with corresponding 
funding status. The technical status is compiled by the 
Project Engineer from monthly reports submitted by the 
functional codes. The funding status is compiled from the 
detail Code 08 computer summary. The monthly status reports 
submitted by the technical codes are received by the SPO/NWC 
ten days after the end of the report month. The Project 
Engineers then integrate these reports and submit the draft 
NAVAIR report to the SPO/NWC Manager. The report is nor- 
mally mailed to NAVAIR by the end of the month following the 
report month. 

The NAVAIR visit action reports are used to provide 
information to NAVAIR on NWC personnel's trips to missile 
component manufacturers' facilities. There are an average 
of twenty visit action reports prepared per month. The 
reports are prepared by the traveler, collected by the 
SPO/NWC and transmitted to PMA-259 by official letter. 

The NWC internal management reports are prepared by 
the Production Manager and Project Engineers. The funding 
data is sximmarized from the same data as the NAVAIR reports 
and the technical aspects are short comments on significant 
problems and/or accomplishments, prepared by the Production 
Manager and Project Engineers, with less detail than the 
NAVAIR reports. The NWC internal management reports are of 
two types: 1) a NWC Commander's report prepared on a monthly 
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basis, and 2) an Engineering Department Head (Highlight) 
report prepared on a weekly basis. The Highlight report 
contains more technical progress and problem details and 
does not contain funding data. 

7 . Program Review Action Items 

Formal program reviews between Navy and component 
contractors personnel are held on a periodic basis. The 
reviews are program production related with program status 
and problems the primary agenda. The results of these 
reviews are formal and semi- formal minutes with action items 
assigned by the Infrared Missiles Program Manager or Assist- 
ant Program Manager (APM) to the contractor, NAVAIR func- 
tional personnel and/or NWC . The SPO/NWC has the responsi- 
bility to see action is taken on all items assigned to NWC. 

The process followed to ensure action item accom- 
plishment depends on the responsible Project Engineer and 
the priorities he assigns to program review action items, 
the type of personnel available within the functional codes 
to respond to his requests, his ability to persuade the 
functional personnel, etc. There is no formal process 
established and each Project Engineer uses his own system to 
assign, track and report status of program review action 
items . 

The volume of action items resulting from any given 
status review meeting is highly variable. For example, the 
number of action items from two consecutive GCS contract 
status review meetings was from four to sixty-two. With an 
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average of one status review meeting per month, this would 
be an average of thirty- three action items SPO/NWC Project 
Engineers must delegate to functional codes, track and 
report status on per month. 
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IV. SIDEWINDER PROGRAM OFFICE (NWC) MICS REQUIREMENTS 



A. BACKGROUND 

To this point, the authors have stated the problem of 
program planning and control as it exists at the SPO/NWC. 

The problem has been presented in general terms and with 
current literature viewpoints on the managerial functions of 
planning and control and MICS considerations. In addition, 
they have detailed the current environment of the SPO/NWC, 
and the systems currently used to provide information for 
planning and control purposes. The previous chapters, 
therefore, represent the first two phases of the MICS system 
life cycle as presented in Chapter I. This chapter will 
address the elements of the third phase in the life cycle - 
the Requirements Phase. The roles, responsibilities and 
information flows described in Chapter III will be consid- 
ered in terms of concepts and considerations presented in 
Chapter II in order to arrive at meaningful system require- 
ments for a MICS to support the needs of SPO/NWC. The 
information and control systems currently in existence at 
SPO/NWC will be evaluated in light of these systems require- 
ments in order to determine the adequacy of their perform- 
ance. The result of this review and evaluation process will 
be a gross MICS design for the SPO/NWC. 

This requirements determination activity, as outlined 
by Rigo, is nothing more than the design process as discus-* 
sed in Chapter II. As previously presented in that chapter. 



Dr. Wilkinson contends that the appropriate design process 
is dictated by the perspective taken with respect to the 
MICS. The authors contend that the appropriate perspective 
for the SPO/NWC MICS is that of a decision-oriented network 
and therefore the appropriate design approach is one of 
defining the required outputs and working backwards to 
specify the input data and conversion processes necessary. 
This contention is made based upon the assumption that the 
information needed within the SPO/NWC for the successful 
accomplishment of the majority of their responsibilities can 
be provided by regularly scheduled reports. This basic 
assumption will be verified as the requirements determina- 
tion/design process is executed in this chapter, with the 
exception of specific instances which will be indicated. 

In executing the design process in this chapter the 
authors will use a modified Burch and Strater approach. The 
initial effort will be the definition of the desired SPO/NWC 
MICS goals and objectives. The current systems will be 
evaluated in terms of their ability to meet these goals and 
objectives. This will be followed by the development of a 
conceptual model of the desired system and the definition of 
required outputs. Finally, the necessary inputs and proces- 
sing will be addressed. 

B. SPO/NWC MICS GOALS AND OBJECTIVES 

It can be seen that the roles and responsibilities of 
the personnel within the SPO/NWC, as described in Chapter 
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Ill, fall into the categories of operational control and 
managerial control in the Anthony framework. The Project 
Engineers are responsible for assuring that specific tasks 
are carried out within their areas of cognizance. The 
Production Manager and the SPO/NWC must coordinate and plan 
to assure that resources are obtained and used effectively 
and efficiently in the accomplishment of the program objec- 
tives. In general, it can be stated that the goals of the 
SPO/NWC MICS are to provide operational control at the 
Project Engineer level, and managerial control at the Pro- 
duction Manager and SPO/NWC Manager level. The adoption of 
this perspective allows, perhaps even requires, the use of 
the information and MICS characteristics and considerations 
appropriate to these categories in the design process of the 
SPO/NWC MICS. Within these two general MICS goals of oper- 
ational and managerial control are various objectives which 
will be discussed in the following sections. 

1. Operational Control 

The first objective of the operational control 
aspect of the MICS is to provide a "closed-loop" task track- 
ing system. Koontz and O'Donnell state that "the basic 
control process, wherever it is found and whatever it con- 
trols, involves three steps: 1) establishing standards, 2) 

measuring performance against these standards, and 3) cor- 
recting deviations from standards and plans. "[10] This de- 
scription implies a "closed- loop" system whereby information 
is fed back to the manager in order for him to measure 
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actual performance against established standards. The 
objective of the task tracking system is to provide a mech- 
anism for the recording of tasks to be accomplished, and a 
means of identifying those tasks which have been completed 
and those which have not in order for the Project Engineer 
to take appropriate action. 

A second objective of the operational control 
subsystem is to provide a uniform or standardized method and 
format for the tracking of tasks within the SPO/NWC organi- 
zation. One of the problems described in Chapter I was the 
lack of uniformity among the individual Project Engineers' 
methods of task tracking which results in considerable 
confusion and research effort when these individuals are 
absent or rotated^ The establishment of a single format or 
method would allow for timely and orderly retrieval of 
information in the absence of any particular’ individual and 
allow for reduced training among Project Engineers in the 
event of position rotation. 

A third objective of the operational control sub- 
system is funding visibility at the JO level. In addition 
to monitoring task accomplishment in terms of schedule and 
performance, the Project Engineers should be able to track 
expenditures on tasks being performed within the functional 
codes and PFAs as appropriate. 

A final objective of the operational control por- 
tion of the MICS is the ability to provide operational 
information for historical purposes. One of the elements of 
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the first operational control objective (closed-loop task 
tracking) was the identification of the actual accomplish- 
ment of an assigned task. While the primary use of this 
information is to highlight the remainder of the tasks, 
i.e., to identify those tasks which have not been completed, 
an equally important aspect is the ability to produce proof 
of task accomplishment and provide the informational results 
of the task completion at some point in the future. The 
MICS must include this capability in order to adequately 
support the SPO/NWC operations . 

2 . Managerial Control 

In order to exercise effective managerial control, 
the decision maker must have visibility into the resource 
areas which he is attempting to manage. The first objective 
of the managerial control subsystem of the MICS is to pro- 
vide visibility into the SPO/NWC organization itself. The 
Production Manager and SPO/NWC Manager must know which 
responsibilities or tasks are not being fulfilled so that 
they may bring additional resources to bear if required. 

This can be accomplished by an overdue task reporting system. 
This system would be an exception reporting system by nature 
and would identify those specific areas which require mana- 
gerial attention. 

The second objective of the managerial control 
subsystem is visibility of external areas essential to the 
accomplishment of program tasks and objectives. These areas 
include the functional codes within NWC and other activities 
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which interact with SPO/NWC, as outlined in Chapter III. 

The Production Manager and SPO/NWC Manager have a need to 
know the level of workload within these activities in order 
to make appropriate resource allocations and tradeoffs in 
light of program goals. The level of workload intended here 
would reflect only SPO/NWC tasks to be performed by these 
activities. This visibility would allow the Production 
Manager and SPO/NWC Manager to establish priorities among 
the various SPO/NWC tasks which a particular activity was to 
perform in the face of limited resources within that organi- 
zation, or to request and/or provide additional resources 
for the completion of critical tasks. 

In addition to the level of workload within the 
-supporting activities, the SPO/NWC Manager needs to know the 
level of funding and expenditures as applicable to the tasks 
performed by these activities. This visibility would only 
be required at the customer order level; however, it would 
be very important in providing insight to resource utiliza- 
tion and progress of task accomplishment. 

A final objective of this managerial control ele- 
ment of the MICS is the recording and processing of his- 
torical task accomplishment data for planning purposes. 

This capability would enable the SPO/NWC Manager to plan 
future workload and funding requirements by providing such 
information as the average task processing time by component 
area by a particular functional code. Another example would 
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be the average cost per task by component area by a func- 
tional code. This would be particularly helpful and appli- 
cable in the processing of ECPs and GDIs. While no model is 
envisioned which would predict with extreme accuracy the 
cost and time parameters of a particular future task, the 
analysis of historical data would provide some insight into 
future resource requirements. 

C. EVALUATION OF CURRENT INFORMATION AND CONTROL SYSTEMS 
1 . Operational Control 

The goals and objectives of an MICS were enumerated 
in the previous section of this chapter. The operational 
control objectives as established are: 1) a closed- loop 

task tracking system, i.e., a means to identify tasks that 
are completed or not completed, 2) a uniform method and 
format for task control, 3) funding visibility at the JO 
level, and 4) a record of completed task data. 

Evaluation of the current MICS against these objec- 
tives highlights the deficiencies or adequacies of present 
practices. The results of this analysis will indicate the 
problem areas that need improvement and point out areas that 
must be dealt with if development of a new system is neces- 
sary. 

A closed-loop task tracking system is the number 
one objective of the SPO/NWC MICS. Neither the correspond- 
ence, filing and distribution system, the task agreement 
system, nor the program review action item system provide 
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the closed-loop system desired. None of these systems, as 
structured, provides the visibility to ascertain if re- 
quested action has been completed. 

The D/CM system, Mark III Management System and 
funding system individually possess the characteristics of a 
closed-loop system. The major problem is that they do not 
tie back into the correspondence system and therefore pro- 
vide a closed- loop only on a subsystem level. In addition, 
these systems require manual updating and information re- 
trieval and siibsequently are very time consuming. Since 
they do not provide due date sequencing or exception data, 
this type of information must be retrieved by a search 
through the entire file. 

As is evident in the discussion of the existing 
SPO/NWC information and control system in the preceding 
chapter, the existing system is made up of a number of 
disjointed systems. There is no uniform method and format 
for task control. Each of the existing systems is designed 
to perform information and control functions in specific 
areas and does not attempt to integrate the information into 
a single format at either the operational or managerial 
levels. As a result, a Project Engineer, the Production 
Manager, and/or the SPO/NWC Manager must go to three or four 
different reports or files to determine the status of work 
under his cognizance. The time required to accomplish this 
is considered excessive. 
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The individual Project Engineers keep their own 
personal tracking system of notebooks or chalkboard entries, 
each with his own format. This makes tracking or interpre- 
tation of status difficult in the absence of one of these 
individuals. The absence of a predetermined format and 
system for: 1) program review action item, and 2) miscel- 

laneous requests for task accomplishment, which do not fall 
into one of the predetermined categories in existence re- 
sults in the loss of data connected with the completion of 
these tasks. In fact, some of the requests probably do not 
ever get accomplished and are never brought to light since 
there is no system to record and track their progress. 

The funding process at the JO level is adequate in 
that a system is available for SPO/NT-JC use. However, as it 
is being used, it does not provide the cost-performance 
tracking of tasks at a level that the Project Engineer 
needs. The mechanism exists but the implementation is 
lacking. The lack of cost visibility at the JO level is a 
problem in each of the current MICS systems. D/CM and Mark 
III systems have JO control but it is at such a level that 
the expenditures for any given ECP review are unknown and 
only averages can be determined. A similar situation exists 
with the program review action items in that all expendi- 
tures for all items in a functional code are charged against 
a general task agreement and no visibility is provided on 
any particular action item task. 
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2 . Managerial Control 



The managerial control objectives of the desired 
SPO/NWC MICS are: 1) visibility into the SPO/NWC organiza- 

tion, 2) visibility into external areas, 3) expenditures 
level summaries, and 4) historical summaries on completed 
tasks. Analysis of the current MICS in light of these 
objectives will determine the adequacies or deficiencies of 
the current practices. 

The current information and control systems, with 
the exception of the funding, do not provide managerial 
visibility into the SPO/NWC. Neither the correspondence and 
filing system, D/CM system, program review action item 
system, nor Mark III system provide, on a scheduled basis, 
any data on past due or delinquent tasks. This type of 
past-due tasks information can be located in D/CM card files 
but it is not readily available. 

A similar situation exists with visibility into the 
SPO/NWC functional support organization. The current infor- 
mation and control systems do not provide any type of excep- 
tion reporting or workload levels. Visibility is available 
through the monthly technical reports on past performance 
only. There is no means to highlight workload difficulties 
and therefore allow the SPO/NWC to set priorities or reallo- 
cate resources. 

The current funding system provides adequate re- 
porting on the financial status of the program at the cus- 
tomer order level. 
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Historical file data using the current information 
and control systems is deficient in that there is no central 
file system to retrieve information on past-due tasks. 
Historical data must be retrieved manually from a diverse 
number and type of files, and subsequently manipulated by 
hand to produce the desired information. 

3 . Summary and Conclusions 

The evaluation of current information and control 
systems, in light of the goals and objectives established by 
the authors, highlights deficiencies in the following areas: 
1) closed-loop tracking, 2) uniform format/methods, 3) 
management visibility, and 4) historical filing. In order 
to eliminate these deficiencies, the authors will present a 
conceptual model of a MICS for the SPO/NWC . 

D. SPO/NWC MICS CONCEPTUAL MODEL 

The conceptual model of the desired SPO/NWC MICS is 
primarily a pictorial or diagrammatic presentation of the 
system inputs and outputs. The system inputs are the var- 
ious means of task and responsibility assignments discussed 
in Chapter III. The outputs consist of reports designed to 
attain the system's overall goals and objectives as discussed 
in the previous section. The conceptual design model of the 
SPO/NWC MICS is presented as Figure IV-1. 
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E. DEFINITION OF SYSTEM OUTPUTS 

This section will discuss in detail the outputs shown 
on the conceptual design model. Each report will be out- 
lined in turn, depicting the specific information fields 
required to prepare the output, the retrieval time and 
frequency needed, the volume of information to be reported, 
and the number, dissemination, and output security involved 
with each. 

1 . Outstanding Tasks Listing 

As described in the previous chapter, the Project 
Engineer is a very key individual in the accomplishment of 
SPO/NWC responsibilities. Correspondence goes directly to 
the appropriate Project Engineer, via the "programmed" 
correspondence distribution system. He is responsible for 
the assignment of tasks to the functional codes and other 
activities and the monitoring of progress on the task comple- 
tion. A viable, comprehensive MICS must provide the Project 
Engineer with an improved capability to discharge his respons- 
ibilities. The purpose of the outstanding tasks listing is 
to. assist the Project Engineer by providing a uniform and 
comprehensive means by which each task assigned to NWC 
functional codes and other activities may be tracked. 

In order to accomplish this, the listing must 
contain the subject of the specific task, the responsible 
code or activity name, the completion due date, the task 
initiating documentation, and the form of the required 
reply. This information will allow the Project Engineer to 
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keep track of what the task is, who is responsible for 
completion, and when completion is required. It also indi- 
cates who or what activity requested the performance of the 
task and what the desired response is to be, i.e., a report, 
letter, memorandum, presentation, etc. The output report 
should also contain an entry indicating the amount of funds 
budgeted or expected to complete the task and the amount 
actually expended as of the report date. This funding 
should be broken down into labor, material, travel, overhead, 
and "miscellaneous" categories. This will enable the Pro- 
ject Engineer to monitor costs concurrently with the sched- 
ule and performance parameters. 

As a means of organizing the multitude of tasks 
which are to be tracked by each Project Engineer, four 
categories should be delineated. There would be ECPs, GDIs, 
Program Review Action Items and other tasks. All the 
information items desired above should be included on spe- 
cific tasks within each of these four categories. In order 
to act as a "tickler" to the Project Engineer, the informa- 
tion items listed above should be presented in due date 
sequence within the four categories. This will enable the 
Project Engineer to see delinquent tasks readily, as well as 
those on the immediate time horizon. 

In addition to the due date sequence listings 
within the four task type categories , a report is also 
needed, arranged in responsible code or activity sequence. 

The information fields would be the same as those in the due 
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date report; however, this listing would highlight the 
workload in the functional codes and other activites as well 
as the schedule and cost performance of these activities. 

The Outstanding Tasks Listing in due date sequence 
would be tailored to each Project Engineer, i.e., each 
Project Engineer would receive a listing showing the tasks 
in his area of cognizance (GCS, AOTD, etc., as applicable.) 

In addition, the D/CM would receive an aggregate listing of 
all ECPs to enable him to ascertain those ECPs which were 
late in the review cycle and those which were nearing the 
due date. The responsible code or activity report would be 
provided to the Production Manager and SPO/NWC Manager to 
give them the visibility into the activity's workload levels 
and enable them to set priorities, make resource alloca- 
tions, and determine if new tasks can be accepted. It could 
also be provided to the functional code heads to give them a 
summary of SPO/NWC work to be performed by their organization. 

A review of the volume of tasks outstanding indi- 
cates that approximately 120 items are outstanding each 
month in the area of AIM-9L production support. These items 
are divided among the four Project Engineers under the 
Production Manager. In order to adequately monitor these 
tasks, the Outstanding Tasks Listing should be provided to 
the Project Engineers on a weekly basis, and the information 
provided shall not be more than seven days old. The respon- 
sible code or activity report should be provided to the 
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Production Manager and the SPO/NWC Manager every two weeks 
and should not present information more than seven days old. 

2 . Overdue Tasks Listing 

The Overdue Tasks Listing would provide the Produc- 
tion Manager and SPO/NWC Manager with visibility into the 
SPO/NWC organization itself and highlight those areas which 
require managerial attention. The information provided 
would be the same as presented in the Outstanding Tasks 
Listing; however, only those unaccomplished tasks which had 
surpassed the completion date would be listed. The Produc- 
tion Manager would receive a weekly listing showing all 
tasks overdue by five or more days and the SPO/NWC Manager 
would receive a weekly listing showing all tasks overdue by 
ten or more days. Both of the reports would be in due date 
sequence; however, the cognizant Project Engineer and func- 
tional code would also be listed so that dissemination of 
this report should be restricted to the Production Manager 
and SPO/NWC Manager only. 

3 . Completed Tasks Listing 

The purpose of the Completed Tasks Listing is to 
provide a record of task accomplishments and thereby close 
the loop which was begun upon the receipt of a request for 
task accomplishment. In addition, it would provide a data 
base for projections of future requirements and capabili- 
ties. The basic information elements which were established 
by the Outstanding Tasks Listing would be retained on the 
Completed Tasks Listing and the completion date, outgoing 
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response identification number (e.g., letter serial number 
message date-time group), total costs, and time to complete 
the task would be added. This listing should be arranged in 
incoming requestor documentation identification number 
sequence in order to tie specific responses to specific 
requests. This would enable SPO/NWC personnel to retrieve 
the requested information at a later time through the use of 
the original requestor identification number. 

Only one listing would be required and should be 
provided on a bi-weekly basis. It should contain the accum- 
ulation of up to the previous six months information. After 
the accumulation of six months information, the last listing 
would be retained and a new cumulative listing would be 
initiated. Based upon the average number of tasks outstand- 
ing, it is anticipated that in a six-month period approxi- 
mately 750 task accomplishments would be recorded. 

4 . Historical Information Summaries 

The planning and estimating for future workloads 
and tasks is an important element of the SPO/NWC Manager 
responsibility. With the application of many years of 
experience and by repeating similar tasks, the planned 
details become more accurate in terms of cost, schedule and 
performance. However, when personnel change, the corporate 
memory is lost and another training period begins . 

The data base established by the Completed Tasks 
Listing would retain the needed task accomplishment data. 
This data could be manipulated to produce information on an 
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"as required" basis to furnish the SPO/NWC Manager with such 
outputs as average time and/or cost for task completion of a 
certain type by a given functional code or PFA. This type 
of information could be used to answer "what if" questions 
and also to evaluate the efficiency of a particular func- 
tional code or PFA. 

5 . Funding Summaries 

Funding summary reports are essential to provide 
the fiscal information necessary to manage the SPO/NWC. 
Funding reports for the managerial level should include 
funding received by NWC, planned expenditures, actual expend 
itures, and cumulative expenditures for the fiscal year by 
customer order. A further breakdown of actual expenditures 
into labor, overhead, material, travel, contracts and miscel 
laneous should be included. The reports should be available 
on a monthly basis. This will allow program visibility in 
time to avoid over expenditures. 

The number of reports would be small since only one 
copy per customer order number is required. AIM-9L produc- 
tion support would have only one report per month. 

The report should be disseminated to the SPO/NWC 
Manager and the Production Manager. The fiscal assistant 
would keep and maintain file copies. The same report could 
then be used for NAVAIR and NWC management reports . 

The summary funding reports would provide a means 
to track and control expenditures at the managerial level. 
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It would be available for upper management reports and 
should not require any output security restrictions. 

F. DEFINITION OF PROCESSING REQUIRED 

Having determined the characteristics of the outputs 
required by the desired SPO/NWC MICS, it is possible to 
provide a general set of requirements for the processing 
function of the system. As described in Chapter II, the 
processing functions can be viewed in terms of response 
time, frequency, data volume, data manipulation and storage 
or file requirements. 

The frequency of the output required and the currency 
of the information desired will affect the response time and 
frequency of the processing operations. In order to provide 
weekly listings with information less than seven days old 
requires a system processing time of one day. The response 
time of the processing function must, therefore, be one day. 
However, the frequency of the update would be weekly. Those 
reports which are required bi-weekly would result in an 
update frequency of bi-weekly with a processing response 
time of one day in order to provide information with a 
currency of seven days. Similarly monthly reports would 
require monthly updating. The "as required" reports would 
not require as immediate a response time. Three days would 
be sufficient to respond to most "what if" questions and 
since the information would be historical, there would not 
be any strict restrictions in the currency of the data. 
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The data volume would be dependent upon the number of 
tasks assigned during the period and ' the amount of data 
recorded for each task. The number of tasks has been pre- 
viously estimated at 120 per month, and the information 
■fields required were enumerated under the discussion of the 
Outstanding Tasks Listing and the Completed Tasks Listing. 

The storage or file requirements would be determined by 
the volume characteristics described above, the number of 
variations of the basic reports required, and the length of 
time for which the data must be retained. The Outstanding 
Tasks Listing has three variations: the due date sequence 

listing, the responsible activity listing and the aggregated 
ECPs listing. The Overdue Tasks Listing would be provided 
in two variations. The Completed Tasks Listing would be a 
single listing with no variations. The funding summaries 
would require arrangement of the data by customer order. 

The Historical Information Summaries would require the 
arrangement of the completed task data by functional code or 
PFA and subject category to enable future processing to 
provide the desired information. The number of files ac- 
tually required to provide the data outputs represented by 
the various reports, will be dependent upon the data proces- 
sing method selected for the MICS. A manual or electromech- 
anical method would require separate files for each. An EAM 
or punched card equipment method could use a single or small 
number of card files and merely re-sort them each time a new 
variation of output is required. An electronic computer 
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could utilize separate file storage or a data base storage 
system as deemed appropriate. 

The outstanding tasks data would be changing constantly 
over a period of time but would retain approximately the 
same volume level as previously indicated. The completed 
tasks data would be retained in a file arrangement for six 
months; therefore, the file would contain about 750 tasks. 

Processing operations would be required to provide the 
listings as described in the output definition section. 

These could be done manually or with machine and the extent 
of processing would be determined by the number and type of 
files maintained. Obviously, if a separate file were main- 
tained for each type of report, no processing would be 
required other than compiling the information into a report 
itself. The Historical Information Summaries would require 
calculation of average cost and time. Also, calculation of 
ranges of values or variances, and standard deviation from 
the mean values could be required. 

G. DEFINITION OF INPUTS REQUIRED 

The input sources for the desired SPO/NWC MICS are 
shown in the Conceptual Design Model (Figure IV-1) . The 
primary personnel to actually input data to the system would 
be the Project Engineers. Upon receipt of a task assign- 
ment, the appropriate Project Engineer would fill out a 
formatted input data sheet with the required information. 
This basic document would then become the instrument for 
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taking the transaction up in the MIGS. Updating would also 
be done by the Project Engineer; however, the insertion of 
the completion data indicating task accomplishment could 
only be done by the Production Manager or SPO/NWC Manager. 
Verification of input data would be required before allowing 
the data to enter the MICS. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



A. SUMMARY 

This thesis represents a comprehensive review of the 
current literature on MICS theory and applications, and a 
thorough review of the current SPO/NWC organization and MICS 
by the authors. Goals and objectives for a viable SPO/NWC 
MICS were established in light of the theoretical management 
practices appropriate, and the needs of the SPO/NWC. An 
evaluation of the current SPO/NWC information and control 
systems was made with respect to the established MICS goals 
and objectives, and the current systems were 'found to be 
deficient as noted in the preceding chapter. An improved 
MICS was therefore deemed necessary by the authors, and a 
conceptual model was presented representing a viable, compre- 
hensive MICS for the SPO/NWC. 

B. CONCLUSIONS 

The authors concluded in Chapter IV that the current 
SPO/NWC information and control systems failed to meet the 
desired performance in the areas of operational control and 
managerial control. Specifically, deficiencies were noted 
in the areas of closed-loop task tracking, uniform format/ 
methods, management visibility, and historical filing. In 
order to eliminate these deficiencies, a conceptual model 
of an improved MICS was presented. The alternatives to 
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providing an improved MICS are the redesign or revision of 
the current MICS, or the design of a totally new MICS struc- 
ture . 

C. RECOMMENDATIONS 

1. MICS Revision and Augmentation 

It is the authors' recommendation that the present 
MICS be revised and augmented. Design of a totally new MICS 
structure is not considered necessary. The revision of the 
existing systems would adapt the adequacies of existing 
systems to the characteristics of 'the conceptual model, and 
the augmentation of currently lacking capabilities would 
provide the feedback and visibility required. 

What is envisioned is an integrated MICS utilizing 
the existing systems' structures but introducing a common, 
uniform, input documentation to provide a single means of 
tracking and recording task accomplishment within the exist- 
ing systems. These existing systems would then become 
subsystems of the integrated MICS. This approach would 
utilize the existing adequacies of these current methods and 
would assist in providing the added operational and manager- 
ial control required. 

The introduction of a feedback mechanism to produce 
a closed-loop task tracking system would provide the infor- 
mation required for adequate operational control and mana- 
gerial control. This information would then become the 
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basis for the reports previously described which are not 
available under the current system. 

2 . Data Processing Method 

The data processing method required for this inte- 
grated MICS could be any of the four methods discussed in 
Chapter II; however, the authors recommend that either an 
EAM or computer method be investigated for application. 

This recommendation is based upon the volume and time con- 
straints represented within the conceptual model, as out- 
lined in Chapter IV. 

3 . Participatory Management and Design 

As pointed out in Chapter IV, the Project Engineer 
is a principal benefactor and key individual in the initia- 
tion and updating of information in the MICS. It is there- 
fore recommended that these individuals be participants in 
the subsequent design and implementation of an improved MICS 
as advocated by the authors. Any MICS can only be effective 
if all concerned understand it and use it to its fullest 
advantage . 

4 . Follow-on Study 

As noted in the Methodology section of Chapter I , 
this thesis represents the first three phases of the MICS 
development cycle. It is recommended that a follow-on study 
be conducted in accordance with the MICS Development Model 
to complete the Preliminary Design and allow the SPO/NWC to 
actively pursue the total design, development and implement- 
ation of the required MICS. 
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SIDEWINDER PROGRAM OFFICE (NWC) 
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EXPLOSIVE 

COMPONENTS 





APPENDIX G 

SPO/NWC-PFA INTERFACES 



SIDEWINDER PROGRAM OFFICER 
CODE 36202 

r NAVAL WEAPONS CENTER 
I CHINA LAKE 



1- PACIFIC MISSILE TEST CENTER 
1 PT. MUGU, CA, 


- ECP LOGISTIC IMPACT 


L FLEET ANALYSIS CENTER 
CORONA. CA. 


- TEST EQUIPMENT CERTIFICATION 


L- NAVAL ORDNANCE STATION 
• INDIAN HEAD, MD. 


- ROCKET MOTOR TECHNICAL SUPPORT 


1- EGLIN AIR FORCE BASE 
1 FT. WALTON BEACH, FL. 


- AIR FORCE TECHNICAL REQUIREMENTS 


* NAVY GAUGE AND STANDARDS LAB 
' POMONA, CA. 


- GAUGES 


1- NAVAL WEAPONS SUPPORT CENTER 
1 CRANE, IN. 


- WARHEAD SUPPORT/MANUFACTURER 


L OGDEN AIR LOGISTICS COMMAND 
1 OGDEN, UTAH 


- IN-SERVICE MISSILE AND UTILIZATION DATA 


r- AIR FORCE TEST AND EVALUATION 
, CENTER. KIRTLAND, N.M. 


- TEST SUPPORT 


NAVAL ORDNANCE LABORATORY 
1 LOUISVILLE 


- CONTAINER PROCUREMENT 


>- NAVAL WEAPONS LABORATORY 
DAHLGREN 


- ELECTROMAGNETIC REQUIREMENTS 
AND TEST 
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APPENDIX H 

SPO/NWC - SIDEWINDER COMPONENT CONTRACTORS INTERFACES 
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SIDEWINDER PROGRAM OFFICE 
CODE 36202 



RAYTHEON COMPANY 

AERONUTRONICS-FORD 

SANTA BARBARA RESEARCH CENTER 

MARTIN MARIETTA 

ROCKETDYNE 

BERMITE 

MICRONICS 

ERI 

CRANE-NAVAL WEAPONS 
SUPPORT CENTER 

LOCKLEY MFG COMPANY 



GUIDANCE & 
SECTION 

GUIDANCE & 
SECTION 

FUSE 

FUSE 

MOTOR 

MOTOR 

SAFETY AND 
DEVICE 

WINGS 

WARHEAD 

FIN 



CONTROL 

CONTROL 



ARMING 
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/ ' n’ 'vd.^K u;i i t ass i GNt:tHT 
k.ayai=! .os;i in:/i (R£v. 9-5o) 



Appendix I 
OEPAaiMEHT OF THE !IAVY 
KAVAL AIK SY5IEHS 

VAVIIMCIC^. O.C. 2C1W 



S«e NAVA in 3”) 00. 8 or 5*»prr5C'Ju 

for »|»pl i C »l»l tr on COrr- 

pletjng iKia fora. 



CLAS^If 

UNCLASSIFIED 


n 

pAce 1 or 


0'4*1 

Commander (Code 55202) 




AiF«rAS< NQ. 

A05P-204/2162/6000/00000 




Naval V/eapons Center 
China Lake, CA 93555 






Liiif SO, 


AUifiO. SO. 








tffo^r utvcL 




KAVAM f«Di4CT 


CCOl 




normal 




V/. Grocme, Jr. 


AIR-05P/ 

ESA-20 


CLA55inCAnO^ Of AT/«U 

UNCLASSIFIED 



1, Th« AIHT ViK/Vf03K>OOCOwIiKXyO!X d 2 »cr ibed b«;low is assigned in accordance vjcK iSe indicated effort le»cl ^nd schedule! Func 
ing sulhnr i lat J on for AlKTAiXS -ill be provided jn separate correspondence. If this AIRTASn>f^^i^OO<H3C^XMjvX^ cannot be accoj* 
plivbcd as assigned, ad»is« the Coaaaader, Naval Air Systeas Cocuaand, and the NAVAlIlSYSCGM Tc.'S' CCOHUlNA'iCR, it applicable. 



No work beyond the planning phase vrill be accomplished unless the 
addressees have funds in hand or 'written assurance thereof. 

2. CAMCELLATIOM, REF£REHC£S, AMD/OR ENCLOSURES: 



3. TECHNICAL INSTRUCTIONS- : 

a. Title : Production Support of Air Launched Guided Missile 

\vea.pon Syst;em.s. 

b. Purpose : The purpose .of this AIRTASK is to assign to the 

NAV!'P^^CFM. T,ai-Q the production support responsibilities for 

Air Launened Guided Missile VJeapon Systems as set forth herein. 

c. B ackground : The policy of the Naval Air Syste.ms Command 

(AIR-05P/ESA-20 ) is to delegate to specified field activities certain 
functions required in support of the production of ALGM (Air Launched 
Guided Missiles). The assignm^ent of Production Support to specified 
field acti^/ities v/ill further consolidate engineering functions and 
provide optimium interface bet’ween Basic Design Engineering, Integrated 
Logistics Support, Maintenance Engineering and Production Support. 

d. Detailed Requir.ements : “Under this AIRTASK M&WPMnmv 

China Lake shall support -KLAVAIR by performing, assigned 

tasks as darected by .M-WA-IR (.AIR-05P/SSA-20 ) in work assignments issued 
relative to Data Managem.ent Support, Configuration Management Support, 
Product Assurance Support, and Admiinistrative Support. 



(1) Data f^ananement Suooort : 



AIRTASK NO. A 05 P- 20 V 216 / 6 OOO/ 

0000 Amend 



(a) Coordinate reviev; and up-dating of data so as to 
provide current data packages for reprocurement of assigned systems , 
related equipment or elements thereof. 

(b) Assist NAVAIR (AIR-05P/ESA-20i| ) in definition of data 
requirements as required. 



(2 ) Configuration Management Support: 



(a) Coordinate configuration mangem.ent (identification 
control, and status accounting) efforts so as to provide current 
product baselines and configuration traceability for assigned system.s 
related equipment or elements thereof. 



(b) Review for system im.pact and submission to NAVAIR of 
recommendatio.ns concerning -Class I ECP and critical/maj or waiver and 
deviation requests. 



(c) Reviev; for system Im.pact of Class II ECP and m.lnor 
v;aiver and deviation requests. Technical approval of Class II ECP 
and minor waiver and deviation requests v.’hen specified by the production 
cntract . 



(d) As required, conduct configuration audits. 

(3) Product Assurance Support: 

(a) Participate in pre- and post-award surveys, quality 
audits, contractor/contracting officer technical meetings and facility 
conferences as required. 

(b) Conduct GLAT (Government Lot Acceptance Testing) or 
provide technical support therefor, as required. 

(c) Perform comparative trend analysis of production test 

data, field test data, and performance data to evaluate- system per- 
formance,. quality, and reliability. .Adverse trends and recomm.endatio.ns 
for corrective action shall'be reported to' NAVAIR (AIR-05P/ESA-20^ ) 
im.medlately . ■ 

(d) Reviev/ production specifications, assembly and test 
instructions, quality assurance procedures, and reliability require- 
nents for assigned systems to determine correlation of assembly, test, 
luality and reliability requirements during production, assembly and 
■,est and delivery of the R?I round to inventory. 

(e) Coordinate quality and reliability efforts to assure 
•cmpatibility of such efforts with system requirements. 
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for each as; 



(f) Provide test 
;igned system. 



AIRTAKS.NO ^ 

A05P-20ii/2l. 6 2/6000/00000 
„ , Amend 0 

equipment certification and correlation 



(g) Maintain management reporting systems as established 
at FMSAEG (Fleet Missile System.s Analysis and Evaluation Group) 

(Code 25). 



(^ ) Administrative Support: 

(a) Coordinate P?A (Participating Field Activities) 
production support budget requests so as to submit to NAVAIR (AIR-05P/ 
ESA-204) one (1) production support budget requirement for each 
assigned system. 



(b) Submit to NAVAIR (AlR-05?/SSA-20^ ) for each assigned 
system a quarterly report containing funds and manhours expended for 
each of the support areas contained in this AIRTASK and allov/ing 
traceability to the PFA level by v;ork unit assignment number. 

k. SCHEDULE: 



This is a continuing .AIRTASK assignment. Effective date is 
12 Sep 1975. 



REPORTS AND DOCUMENTATION 



a. Reports: Reporting and documentation requirements 

defined in the individual b'ORK UNIT ASSIGNMENTS established 
this AIRTASK. 



V7ill be 
under 



6. CONTRACTUAL AND V/ORK AUTHORIZATION AUTHORITY: 



Contracts with industry and v;ork authorization to PFA's (Partici- 
pating Field Activities) to perform portions of this AIRTASK are 
hereby authorized within the limit of funds made available. 

7. - SOURCE AND DISPOSITION OF EQUIP.MENT: 

This AIRTASK includes the authority to dispose of equipment acquired 
by NAVWPNCE^T China . Lake or assigned by NAVAIR for use in connection 

v/ith this AIRT.ASK, unless otherv/ise specified. .at the' time of its 
assignment. . ' - - . , . - 

8, AIRCRAFT REQUIREMENTS ; 

Requiremients for testing (PMT) involving aircraft shall be achieved 
through -normal channels at mavwpnpfm^ nc Lake • • 

. COST ESTIMATE: 

Funding v/ill be estim.ated and allocated by individual WORK UNIT 
ASSIGNMENTS. 
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AIRTASK NO. 

A05P-204/2162/6000/00000 Amend 0 

10. STATUS OF APPLICABLE FUNDS : 

Funding for this AIRTASK v.'ill be provided by separate correspondence. 

11. SECURITY REQUIREMENTS : 

The security clearances of personnel v/orking on projects under 
this AIRTASK and the security classifications on documentation and 
hardv;are associated with this AI.RT.ASK shall be commensurate v;ith the 
classification of that hardware or documentation as determined from, 
the applicabel security regulations. 



Copy to: 

Addressee ( 5) 

PACMISTESTCEN, Pt Mugu 
NAV.^lVIONICPAC , INDIA.NAPOLis 
NAV.AIRDEYCSN , V/arminister , PA 
“SV/C, Dahlgren 
••■ISAEG ANX, Corona 
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DEPARTMENT OF THE NAVY 
HAYAL AIR systems COMMAND 
VASHIRGTOH, D.C. 20360 



See NAVAIR 3900.8 or superaedure 
for applicable details on com- 
pleting thia form. 



. 'aiV (ASX/WORK UNIT ASSIGNMENT 
NAVAIR FOP-< 3930/1 (REV. 9-69) 



cLassimcation 

UNCLASSIFIED 


PAGE 1 OF 1 


AooRCSsee 

Commander (Code 55202) 
Naval Weapons Center 
China Lake, CA 93555 


AIRTASK NO. 

A05P-204/2162/6000/00000 


AMENO. no. 
1 


WORK UNIT NO. 

N/A 


AMENO. NO. 


EFFORT level 

N0R.MAL 


KAVAIR PROjCCT CNGlNeCR CODE 

AIR-05P/ 

W. GROOME. JR. ESA-2 04l 


CLASSIFICATION OF AT/WU 

UNCLASSIFIED 



1. The described be 1 ow IS assigned in accordance with the indicated effort level and schedule. Fund 
ing authorization for AIRTASKS will be provided in separate correspondence. If this c annot be accom- 
plished as assigned, advise the Commander, Naval Air Systema Command, and the NAVAIRSYSCOM T&E CCORDINATOR, if applicable. 



Request that the following changes be made to this AIRTASK: 

a. Change paragraph 3.d.(3) to read: 

(3) Product Assurance Support : (See Note 1) 

b. Add Note 1 as follows: 

Note 1. All efforts expended In support of Product 
Quality Assurance will be at the direction 
of AIR-05P/ESA-4 and as specified by V/ork 
Unit Assignments Issued by same against 
this AIRTASK. 

c. Amend paragraph 8. to read "Not applicable." 



Copy to: 

Addressee (5) 
PMA-259 
AIR-05P/ESA-4 
AIR-05P/ESA-2041D 
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DEPARTMENT OF THE NAVY 

RK UNTT ASSIGNMENT KAVAL AIR SYSTEMS COMMAHO S«« NAVAin 3900.3 or sup-rscdurr 

NAVAIR form 3930/1 (REV. 3-69) WSHIHGTOK, O.C. 20360 for applicable details on com- 

piecing this form. 



CLAS5iric*ncN 

UNCLASSIFIED 


PAGE 1 OF 3 


aoorgs:.il 

Commander 

Naval Weapons Center 
(Code 55202) 

China Lake, CA 93555 


AIRTASK NO. 


AMENO. NO. 


UNIT NO. 

ESA-204/AIM-9L/01 


AMENO. NO. 
0 


EFFORT levee 

Normal 


NAVAIR PROJECT ENGINEER COOE 


CLASSIFICATION OF AT/AU 

Unclassified 



1. The /CiFCW^/V^ORK UNIT .ASS IGiNMLN'T described below is assigned in accordance with the indicated effort level and schedule. Fund- 
ing au thor i lat ion for AIRTASKS will be provided in separate correspondence. If this A2QQX3€ / WORK UNIT ASSIGNMENT cannot be accom- 
plished as assigned, advise the Commander, Naval Air Systems Command, and the NAVAIRSYSCOM TdE CCX)RDINATOR, if applicable. 



2, Cancellation, References and/or Enclosures. 



Ref: AIRTASK A05P-204/2162/ 6000/000000 

3. Technical Instruction . 

Title » AIM-9L In-House Systems Engineering and Production Support Activities. 

Purpose . To define the production support services to be furnished by Naval 
Weapons Center (NAWPNCEN) to the Naval Air Systems Command (NAVAIRSYSCOM) and the 
Naval Weapons Engineering Support Activity (NWESA) for the procurement of the AIM-9L 
SIDEWINDER Missile System. 



c. Background Information . The NA^/TVPNCEN has been providing production support 
on the AIM-9H SIDEWINDER missile under the provisions of the referenced AIRTASK and 
Work Unit Assignment No. A05P-204/AIM-9H/11 . 

d. Detailed Requirements . At the direction and/or with advance concurrence of 
ESA-204, provide the following production support activities: 

(1) Program Support 



(a) As directed by ESA-204 , assist in the preparation of procurement 
requests (PR*s), requests for proposals/quotations (RFP ' s/RFQ ^ s) and contract 
negotiations to assure the continuity of program elements. 



(b) Assist ESA-204 in the resolution of production problems. 



(c) Assist ESA-204 in the resolution of weapon system interface problems, 
i.e., test equipment, avionics, logistics, and support equipment (NARF and NWS). iV A’' 



(d) Participate in Program Review Meetings. 







iifsfi «/ (All /ora «r« 



ESA-204/AIxM-9L/01 



Page 2 of 3 



(2) Product Assurance Support 

(a) Review, analyze and evaluate program reliability and 
maintainability requirements, performance, and demonstrations. 

(b) Assist ESA-204 in the preparation of specifications 
and other documentation or presentations as required. 

(c) Review, analyze and evaluate product assurance program 
requirements, performance and demonstration. 



(3) Data Management Support 

Collate, review, and validate all approved changes on the 
AIM-9L data package. Ensure that the data is updated prior to releasing 
for production procurement. 



(4) Configuration Management 

(a) Evaluate engineering change proposals by performing 
tests on hardware in the NAVl'/PNCEN laboratories or in contractor’s 
facilities, as required, 

(b) Establish production baselines, a master documentation 
control center, and configuration management practices. 

(c) Monitor contractor compliance with the product baseline 
list and other contractual requirements (e.g., reliability, maintainability, 
etc.) and provide such other assistance to the Contractor to resolve 
production problems, specification compatibility problems , and any other 
problems affecting production. 

e. Detailed Program Plan . N/A 



4 . Schedule . 

This is a continuing Work Unit Assignment. 

5. Reports and Documentation . 

a. Submit to ESA-204 a quarterly report containing funds and manhours 
expended for each of the support areas contained in this Work Unit Assignment 
and allowing traceability by Work Unit Assignment Number. 
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b. Provide ESA-'204 with any suggested update, change or additional 
requirements to the current Work Unit Assignment, which is desired for the 
next years effort* The revised Work Unit Assignment will become the basic 
document for budget submissions and is required prior to.l June. 

c* Correspondence relating to this Work Unit Assignment shall be routed 
through ESA-204 or as directed by ESA-204. 



6. Contractual Authority . 

See AIRTASK. 

7. Source and Disposition of Equipment . 

See AIRTASK. 

8. Aircraft Requirements . 

See AIRTASK. 

9 . Cost Estimates . 

To be supplied under separate transmittal. 

10. Status of Applicable Funds . 

Funds will be provided by separate correspondence. 

11. Security Classification Requirements . 

See AIRTASK. 



Copy to: 

.WC 55202 (5) 

PM-259 

ESA-2012A 

ESA-2041D 

AIR-5105B 
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Appendix J. 

INFORMATION FLOW RAW DATA 
INCOMING MESSAGES 



NAVMAG 


2 


MAG-31 


AAFB. 


2 


NAVAIRLANT 


Ft .Mugu 


58 


USDAO/S. 


USS. MIDWAY 


3 


CTF/77 


NARF. 


4- 


NAD/H. 


Kirtland AFB. 


5 


MMMU-1 


CHNAVPERS. 


1 


CTG77Pt .4 


Aero Ford 


10 


FITRON-32 


NASCREPLANT. 


8 


NADC. 


WPAFB . 


7 


MAG-12 


CNO. 


13 


NWESA . 


NSWC . 


3 


EDWARDS AFB. 


NASC. 


38 


MDAC. 


NAV/I . 


1 


V/RAFB . 


FAC/C . 


1 


CINCPACFLT 


NELLIS AFB. 


28 


DCRAVSCOM. 


MAG-15 


2 


RAFB. 


USS. KANSAS-CITY 


1 


Raytheon 


Eglln AFB. 


10 


NFWS 


FLTAC . 


5 


NATC. 


USS. DOWNES 


1 


PMTC/Y. 


AAFB. 


1 


NWS/C . 


MICOM. 


1 


GenDynamics 


VX-4 


2 


NOS/I ; 


DCASD. 


2 


HAC . 


NESC. 


3 


JCS. 


spec. 


5 


NTEC. 


eSAF. 


6 


CMC 


NWSC. 


1 


FMFPAC . 


FAIRWESTPAC . 


1 


FITAEWWINGPAC 


CNAPA. 


8 


USS. RANGER 


OPTEVFOR . 


1 


ATKRON-174 


CNM. 


2 


MAG-B. 


IPIMCO. 


1 


SECNAV. 


CNAVRES. 


2 


NAVAIRPAC . 


NASCREPAC. 


2 


LABF. 


NAVFITWPSCOL. 


2 


NAS/M. 


NWS/Y . 


1 


CINCLANTFLT 

NFWS 



TOTAL 313 
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1 
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INCOMING LETTERS AND SPEEDLETTERS TO CODE 36202 
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TASK AGf;££f'.£KT - 1 M £fi0t:PAf;T:-:£fi7AL 


, Appendix 


AMeRO*<£NT 


DATE 




ii!iO-f;.;c-392o/i9 0 - 76 ) PAST 1 


I D- 19-76 






1 c-2 



pbcgr>^' 



AJM-9L PRODUCTION SUPPORT 



COG cell 
36202 


C03fJI2Ai;T D£; = » = T:-’EHT coijtact 

R. W. Doucette 


CCDt 

3362 


PcRf OBMI f.'S eng: NEER/KAtiAGER 

T. W. Hamoton 


C-PQ Div 


DIVISION HEAD SIGNATURE 


PERF DIV 


DIVISION HEAD SIGNATURE 
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TAdAliI^t I 

AIM-9L PRODUCTION ENGINE£RING/MONTTORING FOR AFT CQMPOMF.MT^ i:^R7?n * 

OeSCRIPTION OF WORK REQUIRED; 



Provide technical monitoring and production support of the AIM-9L procurement program for rocket 
motors, warheads, safety-arming devices, wings fins and coupling rings. 

Responsibilities include data, configuration and product assurance support to NAVAIR, the Side- 
winder Program Office, prime contractors and subcontractors. 



APPROACH TO SE TAKEN: 

DATA SUPPORT: Generate, review and interpret baseline drawings and specifications. Review 
and evaluate Engineering Change Proposals (ECPs), Specifications Change Notices (SCNs), Waivers 
and Deviations. Maintain documentation technical content accuracy. 

CONFIGURATION SUPPORT: Perform necessary review to verify that production hardware matches 
the design equations. Resolve incompatabilities between hardware and design. Provide fabrication 
proceedures to contractors and assist in the resolution of production problems. Support Level-of- 
Effort contracts and propose design changes to improve producibility. Evaluate special designs and 
hardware modifications and estimate the cost impact of design changes including implementation 
and production costs. 

PRODUCT ASSURANCE SUPPORT: Participate in pre- and post-award surveys, quality audits, 
contractor/contracting officer technical meetings and facilities conferences. Maintain facilities 
and perform quality assurance, acceptance qualification and failure analysis testing. Review and 
evaluate contractors production, test, handling and assembly procedures to improve producibility. 
Perform first article inspections and tear downs as required. Conduct failure mode studies to improve 
reliability. Perform design and certification of special test equipment for use during the production 
contract. 



REPORTING: 

Monthly reports in the format of enclosure (1) will be submitted to the Program Office no later 
than the 10th of the following month. 



♦funding? 

Applicable Job Orders: 

ACF — Safety and Arming Device ACI — Wings aiid Fins 
ACG — Warhead 
ACH — Rocket Motor 
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i;SK A3S££r-C/JT • 

1 i.‘j;-f-WC-3??o /l9 (1-7^ 

'!'•»• rijr?; 



CESAST^CNTAL 



TASK NO 



) ?A?T 2 



• 


Af- F?iv**EM 


OATS 


AGt 








2ct2 



iicm: ^ 

This is a continuing task assignment. 



?£S 0 UPCE ScCU! =>£•'£>:£$ (Funds) 



1>3C= 1 0Vc3H£A0 


AL8 


TRAVEL 


CCMTPACTS 


T^'AMSFERS 


TOTAL 


FY 77 




— 








ACF 10 (.2) 




2 






12K 


ACG 24 (.5) 




0 






24 xK 


ACH 9 (.2) 




2 






IIK 


ACI 24 (.5) 




2 






2SK 














Jotal S7 (1.^ 


) 


6K 









CRITICAL /.Afi=e.-l£S 



D! <JC1 PLI Me/nA^'E 


NU-tS£P 


vanhcors 


SCHEDULE »TEM 


N/A 




• 






- 



n/a 



OG 0 £PT :-CR (Initial): 



£:<Tr*.C°GAM!ZATIO\AL FACILITICS, £0l.l!P”£.*)T , SERVICES 



ITEM 


SOURCE 


AMOUNT 


SCHEDULE 











P£RF DEPT ^'GR (initial): 



SAMPLE MONTHLY REPORT 



FROM (Reporting Code) '' 

TO Sidewinder Program Office, Code 36202 

SUBJ (month) Report of Sidewinder Tasks 

1. Customer Order Title and No. (Sidewinder AIM-9L Production, 1367205) 

a. Job Order No. (ANA) 

(1) ACCOMPLISHMENTS 
Summary of: 

1) tests completed 

2) publications completed 

3) reports completed 

4) drawings completed 

5) significant correspondence 

6) significant events/break-thrus 

(2) PROBLEMS 

Summary of problems encountered. 

(3) TRAVEL 

Summary of travel including purpose and results. 

(4) VIP Visits 

Summary of visitors including purpose and results of visits. 

b. Job Order No. (ANB) 

(Same format as l.a. above.) 

2. Customer Order Title and No. (Sidewinder AIM-9H Production. 1367705 
(Same format as 1. above.) 



(Reporting Official) 



Enclosure (1) 
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APPENDIX L 

CLASS n ECPs AND MINOR DEVIATIONS AND WAIVERS 
SIDEWINDER AIM-9H/L CHANGE LOW DIAGRAM (CONTRACTOR SUBMITTED) 
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